KDC logging

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

KDC logging

Harald Barth-2

I see that there is no real logging about what tickets the KDC hands
out. Maybe if one goes up to logging level 5 and puts together several
rows of output. Do you think there is a need to make some logging that
really tells that? One example would be in _kdc_as_rep() near the
label out:.

What shoud I use from the request that can be printed as a uniqe
identier in that log?

Harald.



Reply | Threaded
Open this post in threaded view
|

Re: KDC logging

Måns Nilsson-3
Subject: KDC logging Date: Fri, Mar 20, 2015 at 03:41:13AM +0100 Quoting Harald Barth ([hidden email]):
>
> I see that there is no real logging about what tickets the KDC hands
> out. Maybe if one goes up to logging level 5 and puts together several
> rows of output. Do you think there is a need to make some logging that
> really tells that? One example would be in _kdc_as_rep() near the
> label out:.
>
> What shoud I use from the request that can be printed as a uniqe
> identier in that log?

I would find that usable as well.

--
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
HAIR TONICS, please!!

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: KDC logging

Jeffrey Hutzelman
In reply to this post by Harald Barth-2
On Fri, 2015-03-20 at 03:41 +0100, Harald Barth wrote:
> I see that there is no real logging about what tickets the KDC hands
> out. Maybe if one goes up to logging level 5 and puts together several
> rows of output. Do you think there is a need to make some logging that
> really tells that? One example would be in _kdc_as_rep() near the
> label out:.
>
> What shoud I use from the request that can be printed as a uniqe
> identier in that log?


As it stands now, the KDC will log a message "sending %d bytes to..."
for every request which actually results in a response.  This is handled
in one place, when actually sending the reply, so no cases are missed.
In order to know everything that happened while processing a request,
you need to look at all the lines since the previous request up until a
response is sent.  Of course, there are a few cases where there is some
problem which results in not sending a reply; those would have to be
identified separately.

If you specifically want to track tickets the KDC is handing out, then
yes, you'll want to log somewhere near the end of _kdc_as_rep() and
_kdc_tgs_rep(), and you may also want logging for KX509, which issues
certificates rather than tickets, and digest, which does neither.

Unfortunately, neither requests nor tickets really contain a
straightforward identifier you can use.  The best thing I can suggest is
to log a hash (or possibly a truncated hash) of the issued ticket, and
also log the hashes of any tickets in incoming requests (this requires
additional logging in the TGS, in FAST, and when issuing U2U tickets).

I would also suggest adding a fixed log message at the _start_ of
processing each type of request, more or less at the same place in
process.c that sets *claim=1 for each service.  This, together with the
existing logging when a reply is sent, will make it easier to identify
which lines belong together as a single request, even in the presence of
requests that result in no reply.

-- Jeff


Reply | Threaded
Open this post in threaded view
|

Re: KDC logging

Benjamin Kaduk-2
On Sat, 21 Mar 2015, Jeffrey Hutzelman wrote:

> Unfortunately, neither requests nor tickets really contain a
> straightforward identifier you can use.  The best thing I can suggest is
> to log a hash (or possibly a truncated hash) of the issued ticket, and
> also log the hashes of any tickets in incoming requests (this requires
> additional logging in the TGS, in FAST, and when issuing U2U tickets).

MIT krb5 1.12 introduced an experimental pluggable interface for KDC
auditing, which also uses a ticket hash as an identifier. [0] One could
imagine scenarios in which this ticket ID might be used for
organization-wide audit records originating on application servers, e.g.,
outside of just the KDC.  It might be nice to agree on a standard
ticket->identifier mapping, hash or otherwise, that can be common to
Kerberos implementations.  Since this pluggable interface is considered
experimental, non-backwards-compatible changes would be acceptable, if the
current scheme is found to be deficient.  (I don't remember why
CKSUMTYPE_RSA_MD5 was chosen.)

-Ben

[0]
https://github.com/krb5/krb5/blob/krb5-1.12-final/src/kdc/kdc_audit.c#L139-L172
Reply | Threaded
Open this post in threaded view
|

Re: KDC logging

Jeffrey Hutzelman
On Sun, 2015-03-22 at 16:06 -0400, Benjamin Kaduk wrote:

> On Sat, 21 Mar 2015, Jeffrey Hutzelman wrote:
>
> > Unfortunately, neither requests nor tickets really contain a
> > straightforward identifier you can use.  The best thing I can suggest is
> > to log a hash (or possibly a truncated hash) of the issued ticket, and
> > also log the hashes of any tickets in incoming requests (this requires
> > additional logging in the TGS, in FAST, and when issuing U2U tickets).
>
> MIT krb5 1.12 introduced an experimental pluggable interface for KDC
> auditing, which also uses a ticket hash as an identifier. [0] One could
> imagine scenarios in which this ticket ID might be used for
> organization-wide audit records originating on application servers, e.g.,
> outside of just the KDC.  It might be nice to agree on a standard
> ticket->identifier mapping, hash or otherwise, that can be common to
> Kerberos implementations.  Since this pluggable interface is considered
> experimental, non-backwards-compatible changes would be acceptable, if the
> current scheme is found to be deficient.  (I don't remember why
> CKSUMTYPE_RSA_MD5 was chosen.)

Probably because an unkeyed checksum was wanted, and there aren't any
newer ones in the RFC3961 framework.  I don't think MD5 is a terrible
choice for this usage.  It might be worth considering SHA-1, if only to
avoid introducing a new dependency on an algorithm that's almost dead in
Kerberos.

I hope we're talking about hashing the DER encoding of 'Ticket'?

Reply | Threaded
Open this post in threaded view
|

Re: KDC logging

Benjamin Kaduk-2
On Tue, 24 Mar 2015, Jeffrey Hutzelman wrote:

> I hope we're talking about hashing the DER encoding of 'Ticket'?

Dereferencing the footnote yields

    ret = krb5_c_make_checksum(context, CKSUMTYPE_RSA_MD5, NULL, 0,
                               &ticket->enc_part.ciphertext, &cksum);
-Ben