Proposed libkrb5 APIs for name attributes

[Alexander Bokovoy]

Hi Greg,

On ke, 31 heinä 2019, Greg Hudson wrote:
>Right now a GSS server application can get access to PAC information and
>auth indicators using the RFC 6680 APIs (such as
>gss_get_name_attribute()) on the src_name returned by
>gss_accept_sec_context().
>
>The libkrb5 interfaces used to implement these APIs are private:
>krb5_auth_con_get_authdata_context() to get a krb5_authdata_context (a
>private type) and then a set of functions like
>krb5_authdata_get_attribute().
>
>I understand that Samba needs to access auth indicators in a non-GSS
>server application.  Rather than bring the whole set of
>krb5_authdata_context interfaces into the public API, I am inclined to
>add just one or two new auth context APIs:
>
>    krb5_error_code KRB5_CALLCONV
>    krb5_auth_con_get_attribute(krb5_context context,
>                                krb5_auth_context auth_context,
>                                const krb5_data *attribute,
>                                krb5_boolean *authenticated,
>                                krb5_boolean *complete, krb5_data *value,
>                                krb5_data *display_value, int *more);
>
>and maybe:
>
>    krb5_error_code KRB5_CALLCONV
>    krb5_auth_con_get_attribute_types(krb5_context context,
>                                      krb5_auth_context auth_context,
>                                      krb5_data **attrs);
>
>    void KRB5_CALLCONV
>    krb5_free_data_list(krb5_context context, krb5_data *list);
>
>But first I'd like to confirm that these would be sufficient.

Simo and I were discussing AIs integration in Samba. We agreed it is
better to prefer to transform indicators to a content in MS-PAC record
that we create at KDC side (and do a reverse translation for cross-realm
tickets).

This would not require any additional public API exposed to non-GSS
applications.  However, it would require exposing AI APIs to KDB
drivers. Such API would be consumed by both Samba AD and FreeIPA
implementations of KDB drivers.

On Samba file server side we then can add a mapping of asserted
idenities SIDs to access controls of shares. Samba already converts SIDs
from MS-PAC to a membership information in NT security token.

On Samba side we would only need a better way for users to specify the
SIDs (S-1-18-*) that represent asserted identities from MS-DTYP[1] in
Samba configuration as they aren't mapped to POSIX identities and
specifying them in POSIX ACLs would be ugly. However, this is internal
task for Samba.

Asserted identities as well-known SIDs were first added in Windows
Server 2012 (see [2] for some details) with constrained delegation, but
later were extended to handle cases with PKINIT and MFA authentication
in Windows Hello for Business[3].

So far, requirements towards such KDB API would be:
  - KDB driver needs to read AIs before parsing or creating new MS-PAC
    in order to be able to map AIs to some asserted identities SIDs in
    the PAC.

  - KDB driver needs to be able to set AIs after MS-PAC parsing in order
    to be able to map asserted identities SIDs from the PAC to AIs.

  - KDB driver needs to be able to filter/extend AIs based on its own
    criteria.

I believe we also need a similar set of requirements to allow mapping
AIs when they come from a trusted realm but without use of MS-PAC.

For MS-PAC handling, this practically means sign_authdata callback needs
an easy way to consume existing AIs and return new AIs, without
marshalling/unmarshalling them in encrypted ticket reply. The way how it
is done currently in src/kdc/kdc_authdata.c:handle_authdata() is this:

    /* Add auth indicators if any were given. */
    if (auth_indicators != NULL && *auth_indicators != NULL &&
        !isflagset(server->attributes, KRB5_KDB_NO_AUTH_DATA_REQUIRED)) {
        ret = add_auth_indicators(context, auth_indicators, server_key,
                                  local_tgt, enc_tkt_reply);
        if (ret)
            return ret;
    }

    if (!isflagset(enc_tkt_reply->flags, TKT_FLG_ANONYMOUS)) {
        /* Fetch authdata from the KDB if appropriate. */
        ret = fetch_kdb_authdata(context, flags, client, server, header_server,
                                 client_key, server_key, header_key, req,
                                 for_user_princ, enc_tkt_req, enc_tkt_reply);
        if (ret)
            return ret;


        /* Validate and insert AD-SIGNTICKET authdata.  This must happen last
         * since it contains a signature over the other authdata. */
        ret = handle_signticket(context, flags, client, server, local_tgt,
                                req, for_user_princ, enc_tkt_req,
                                enc_tkt_reply);
        if (ret)
            return ret;
    }


So, if there would be a way to pass a mutable list of authentication
indicators to fetch_kdb_authdata() (which would pass it to a KDB's
sign_authdata callback) and add it to the ticket reply afterwards, that
would solve our case.

[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
[2] https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview
[3] https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview

-- 
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland