Proposed libkrb5 APIs for name attributes

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposed libkrb5 APIs for name attributes

Greg Hudson
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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

KDB access to auth indicators (was Re: Proposed libkrb5 APIs for name attributes)

Greg Hudson
On 8/3/19 4:08 AM, Alexander Bokovoy wrote:
> 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.

Please have a look at https://github.com/krb5/krb5/pull/965 and see if
that will work.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: KDB access to auth indicators (was Re: Proposed libkrb5 APIs for name attributes)

Alexander Bokovoy
On ke, 07 elo 2019, Greg Hudson wrote:
>On 8/3/19 4:08 AM, Alexander Bokovoy wrote:
>> 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.
>
>Please have a look at https://github.com/krb5/krb5/pull/965 and see if
>that will work.
Thanks. This looks good. I'm at Flock conference this week but I'll try
to change FreeIPA to see if it works for OTP tokens, i.e. if I would be
able to deny access to a specific Samba share if user doesn't possess
2FA asserted SID in the MS-PAC.

--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev