[35913] in Kerberos
Re: On credential cache separation between service ticket and TGT
daemon@ATHENA.MIT.EDU (Greg Hudson)
Mon Mar 24 15:53:05 2014
Message-ID: <53308D0A.6070200@mit.edu>
Date: Mon, 24 Mar 2014 15:52:42 -0400
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Arpit Srivastava <arpit.orb@gmail.com>
In-Reply-To: <CAEvOXU7LYxPnOZNTZTtwvpyUjuaTsX9p=bXTuCNDnTmXzmXALQ@mail.gmail.com>
Cc: kerberos <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
