Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari - Kerberos

This is a discussion on Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari - Kerberos ; Some comments on this approach. It appears that you are trying to correct a fundalmental problem in the underlying Kerberos gss implementation. On the server/acceptor side, if the gss_acquire_cred is called with a GSS_C_NO_NAME, (or the gss_init_sec_context is not passwd ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari

  1. Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari

    Some comments on this approach. It appears that you are trying
    to correct a fundalmental problem in the underlying Kerberos
    gss implementation.

    On the server/acceptor side, if the gss_acquire_cred is called
    with a GSS_C_NO_NAME, (or the gss_init_sec_context is not passwd
    a crede_handle) then any principal in the keytab should
    be acceptable,

    In the MIT krb5-1.4.1 if the call to krb5_rd_req in
    accept_sec_context.c: at line 405 has the cred->princ == NULL
    then the krb5_rd_req will look in the keytab for the principal
    requested by the client.

    We have a mod for this, see attachment, which would also allow for
    a service principal in multiple realms. This mod was sent to the
    Kerberos list a few years ago but never acted on by MIT. as far as I know.

    Looking at the Heimdal code it looks like it will pass in NULL to krb5_rd_req
    and work similiar to our mod.

    Solaris 10 also appears to work like our mod as well. Its only the MIT
    that does not.





    Russ Allbery wrote:

    > Pepijn Oomen writes:
    >
    >
    >>Sounds interesting. Can you point me to where that patch is to be found?
    >>CVS, mail, patches?

    >
    >
    > I mailed it to the list a few days ago, but the Sourceforge archives kind
    > of suck. Here it is again.
    >
    > diff -urNad libapache-mod-auth-kerb~/README libapache-mod-auth-kerb/README
    > --- libapache-mod-auth-kerb~/README 2006-03-30 17:19:51.000000000 -0800
    > +++ libapache-mod-auth-kerb/README 2006-06-19 10:42:53.000000000 -0700
    > @@ -67,6 +67,10 @@
    > around problems with misconfigured DNS. A corresponding key of this name
    > must be stored in the keytab.
    >
    > + Normally, you do not want to use this option. Instead, put every key that
    > + a browser may want to use into the keytab specified by Krb5Keytab (see
    > + below), and mod_auth_kerb will try each one of them in turn.
    > +
    > Krb4Srvtab /path/to/srvtab
    > This option takes one argument, specifying the path to the Kerberos V4
    > srvtab. It will simply use the "default srvtab" from Kerberos V4's
    > @@ -106,11 +110,19 @@
    > needed when the Negotiate method is used. In this case the module acts as a
    > standard kerberos service (similarly to e.g. kerberized ssh or ftp servers).
    > Default name of the service key is HTTP/@REALM, another
    > -name of the first instance can be set using the KrbServiceName option. The key
    > -must be stored in a keytab on a local disk, the Krb5Keytab and Krb4Srvtab
    > -options are used to specify the filename with the keytab. This file should be
    > -only readable for the apache process and contain only the key used for www
    > -authentication.
    > +name of the first instance can be set using the KrbServiceName option or by
    > +putting multiple keys in the keytab and letting the module try each one in
    > +turn. The key must be stored in a keytab on a local disk, the Krb5Keytab and
    > +Krb4Srvtab options are used to specify the filename with the keytab. This file
    > +should be only readable for the apache process and contain only the key used
    > +for www authentication.
    > +
    > +Be aware that different browsers will try different principal names. Firefox
    > +will do a forward and reverse lookup of the remote IP address to canonicalize
    > +the server name and then use that fully-qualified name in the principal (after
    > +HTTP/). The most recent 10.4 version of Safari will instead use the fully
    > +qualified server name from the URL without canonicalization. Older versions of
    > +Safari may use the unqualified name of the server (after HTTP/).
    >
    > Ticket File/Credential Cache Saving
    > -----------------------------------
    > diff -urNad libapache-mod-auth-kerb~/src/mod_auth_kerb.c libapache-mod-auth-kerb/src/mod_auth_kerb.c
    > --- libapache-mod-auth-kerb~/src/mod_auth_kerb.c 2006-06-19 10:35:26.000000000 -0700
    > +++ libapache-mod-auth-kerb/src/mod_auth_kerb.c 2006-06-19 10:37:49.000000000 -0700
    > @@ -1197,6 +1197,12 @@
    > authenticate_user_gss(request_rec *r, kerb_auth_config *conf,
    > const char *auth_line, char **negotiate_ret_value)
    > {
    > + krb5_context ctx;
    > + krb5_keytab keytab;
    > + krb5_kt_cursor cursor;
    > + krb5_keytab_entry entry;
    > + int k5_errno;
    > + char *principal = NULL;
    > OM_uint32 major_status, minor_status, minor_status2;
    > gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER;
    > gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
    > @@ -1237,10 +1243,6 @@
    > #endif
    > }
    >
    > - ret = get_gss_creds(r, conf, &server_creds);
    > - if (ret)
    > - goto end;
    > -
    > /* ap_getword() shifts parameter */
    > auth_param = ap_getword_white(r->pool, &auth_line);
    > if (auth_param == NULL) {
    > @@ -1267,6 +1269,34 @@
    > gss_accept_sec_context_spnego : gss_accept_sec_context;
    > #endif
    >
    > + /* We're going to try accepting the context with every different principal
    > + available in our keytab if we can. Otherwise, we're going to fall back
    > + on just doing this once with the specified principal name. If k5_errno
    > + is zero, we're walking through the keytab; otherwise, we're not. */
    > + k5_errno = krb5_init_context(&ctx);
    > + if (k5_errno == 0) {
    > + if (conf->krb_5_keytab)
    > + k5_errno = krb5_kt_resolve(ctx, conf->krb_5_keytab, &keytab);
    > + else
    > + k5_errno = krb5_kt_default(ctx, &keytab);
    > + }
    > + if (k5_errno == 0)
    > + k5_errno = krb5_kt_start_seq_get(ctx, keytab, &cursor);
    > +
    > + /* Here's the big loop in which we try to do the authentication. */
    > + do {
    > + if (k5_errno == 0)
    > + k5_errno = krb5_kt_next_entry(ctx, keytab, &entry, &cursor);
    > + if (k5_errno == 0)
    > + k5_errno = krb5_unparse_name(ctx, entry.principal, &principal);
    > + if (k5_errno == 0)
    > + conf->krb_service_name = principal;
    > +
    > + ret = get_gss_creds(r, conf, &server_creds);
    > + if (ret)
    > + goto end;
    > +
    > + /* pridat: Read client Negotiate data of length XXX, prefix YYY */
    > log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, "Verifying client data using %s",
    > (accept_sec_token == gss_accept_sec_context)
    > ? "KRB5 GSS-API"
    > @@ -1307,6 +1337,7 @@
    > gss_release_buffer(&minor_status2, &output_token);
    > set_kerb_auth_headers(r, conf, 0, 0, *negotiate_ret_value);
    > }
    > + } while (k5_errno == 0 && GSS_ERROR(major_status));
    >
    > if (GSS_ERROR(major_status)) {
    > if (input_token.length > 7 && memcmp(input_token.value, "NTLMSSP", 7) == 0)
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari

    Douglas E Engert writes:

    > Some comments on this approach. It appears that you are trying to
    > correct a fundalmental problem in the underlying Kerberos gss
    > implementation.


    Well, actually, I'm doing GSSAPI cargo cult programming, but your way of
    phrasing that sounds so much nicer and more sophisticated.

    > On the server/acceptor side, if the gss_acquire_cred is called with a
    > GSS_C_NO_NAME, (or the gss_init_sec_context is not passwd a
    > crede_handle) then any principal in the keytab should be acceptable,


    > In the MIT krb5-1.4.1 if the call to krb5_rd_req in
    > accept_sec_context.c: at line 405 has the cred->princ == NULL then the
    > krb5_rd_req will look in the keytab for the principal requested by the
    > client.


    > We have a mod for this, see attachment, which would also allow for a
    > service principal in multiple realms. This mod was sent to the Kerberos
    > list a few years ago but never acted on by MIT. as far as I know.


    Aha! So this doesn't work currently with MIT Kerberos but would if your
    patch were applied? Am I reading your message correctly?

    Is this patch already in RT?

    --
    Russ Allbery (rra@stanford.edu)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari



    Russ Allbery wrote:

    > Douglas E Engert writes:
    >
    >
    >>Some comments on this approach. It appears that you are trying to
    >>correct a fundalmental problem in the underlying Kerberos gss
    >>implementation.

    >
    >
    > Well, actually, I'm doing GSSAPI cargo cult programming, but your way of
    > phrasing that sounds so much nicer and more sophisticated.
    >
    >
    >>On the server/acceptor side, if the gss_acquire_cred is called with a
    >>GSS_C_NO_NAME, (or the gss_init_sec_context is not passed a
    >>cred_handle) then any principal in the keytab should be acceptable,

    >
    >
    >>In the MIT krb5-1.4.1 if the call to krb5_rd_req in
    >>accept_sec_context.c: at line 405 has the cred->princ == NULL then the
    >>krb5_rd_req will look in the keytab for the principal requested by the
    >>client.

    >
    >
    >>We have a mod for this, see attachment, which would also allow for a
    >>service principal in multiple realms. This mod was sent to the Kerberos
    >>list a few years ago but never acted on by MIT. as far as I know.

    >
    >
    > Aha! So this doesn't work currently with MIT Kerberos but would if your
    > patch were applied? Am I reading your message correctly?


    Its been a long time, since I tested the MIT without the patch. The MIT
    code comments say it tries to fill in the cred->princ, but I don't see where
    it does this and it could be it leaves it NULL.

    The first test would be to not have mod_auth_kerb pass in a desired_name to
    gss_accquire_cred, and see if the cred->princ is NULL. That might be the only
    thing needed!

    The patch was added to let krb5_rd_req use any entry in the keytab, even if
    a desired_name was passed, check only the service and host. This is consistent
    with the gss_import_name which only allows the application to specify
    the service and host and not the realm, therefore don't assume the realm.

    >
    > Is this patch already in RT?


    Not sure.


    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  4. Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari

    Sam Hartman writes:

    > We believe that current MIT Kerberos should accept any principal in the
    > keytab if no acceptor name is passed into gss_accept_sec_context.


    I've confirmed that this works (at least with 1.4.3). I haven't yet
    updated my mod-auth-kerb patch. This will let it be significantly
    simplified.

    --
    Russ Allbery (rra@stanford.edu)
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  5. Re: [modauthkerb] mod_auth_kerb, virtualhost and Firefox/Safari

    >>>>> "Douglas" == Douglas E Engert writes:

    Douglas> The patch was added to let krb5_rd_req use any entry in
    Douglas> the keytab, even if a desired_name was passed, check only
    Douglas> the service and host. This is consistent with the
    Douglas> gss_import_name which only allows the application to
    Douglas> specify the service and host and not the realm, therefore
    Douglas> don't assume the realm.


    We believe that patch would break the intended functioning of the API.


    We believe that current MIT Kerberos should accept any principal in the keytab if no acceptor name is passed into gss_accept_sec_context.
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread