[35914] in Kerberos
Re: On credential cache separation between service ticket and TGT
daemon@ATHENA.MIT.EDU (Arpit Srivastava)
Tue Mar 25 11:19:18 2014
MIME-Version: 1.0
In-Reply-To: <53308D0A.6070200@mit.edu>
Date: Tue, 25 Mar 2014 20:49:06 +0530
Message-ID: <CAEvOXU43sOSmzuLkbJh88ADjAU=ws_2t4ZjEyo5vDToOf26cbw@mail.gmail.com>
From: Arpit Srivastava <arpit.orb@gmail.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Thanks,
I realized that the problem was with renaming the krb5cc file. For testing,
I was renaming the krb5cc file that contained only the service tickets,
however, when I used the one without renaming it - it worked.
I have one more doubt:
I call gss_init_sec_context with say, *time_req = 20 mins. *Every time the
service ticket hence obtained expires, a new service ticket is obtained
with 20 mins validity, instead of renewing the one already existing in the
cache (so, there are two tickets of same SPN but with different validity
time stamps). I observed that if I pass time_req = GSS_C_INDEFINITE, the
same ticket is renewed and a new ticket is not created. It would be great
if you can provide some insights.
Best,
Arpit
On Tue, Mar 25, 2014 at 1:22 AM, Greg Hudson <ghudson@mit.edu> wrote:
> On 03/24/2014 02:23 PM, Arpit Srivastava wrote:
> > I followed the steps you described in your previous mail, however, what
> > I observed is that if TGT is not present in cache file -
> > gss_init_sec_context fails with min_status KRB5_CC_NOTFOUND.
>
> If I create a ccache with only a service ticket using kinit -S, I can
> successfully run ssh or the GSS sample application. So there is no
> general restriction of this kind.
>
> > klist output:
> >
> > Service principal
> > krbtgt/EXAMPLE.COM@EXAMPLE.COM
> > HTTP/homepage.example.com@
> > HTTP/homepage.example.com@EXAMPLE.COM
> >
> > KerberosApp.trace:
> >
> > [12780] 1395683631.292486: Retrieving user@EXAMPLE.COM -> HTTP\/
> > homepage.example.com/example.com@ from
> > FILE:/etc/local/kerberos/ccache/krb5cc with result: 0/Unknown code 0
> > [12780] 1395683631.294109: Creating authenticator for user@EXAMPLE.COM ->
> > HTTP\/homepage.example.com/example.com@, seqnum 1032037665, subkey
> > aes256-cts/2942, session key aes256-cts/904D
>
> That doesn't look right at all.
> "HTTP\/homepage.example.com/example.com@" is not the same as
> "HTTP/homepage.example.com" and does not appear as the service entry in
> the ccache. I don't see how this lookup could succeed. That principal
> name looks like the result of misusing gss_import_name by specifying
> GSS_C_NT_HOSTBASED and the string form of a Kerberos principal instead
> of a host-based name ("service@host").
>
> Since I don't understand why the lookup is succeeding in the successful
> case, I also have no idea why the lookup is failing in the failure case.
>
> > Could it be because session keys not being there in krb5cc file (I think
> > authenticator is generated using session keys) ?
>
> Each entry in the ccache contains a ticket session key; a TGT is not
> special this regard.
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
