Seriously abusing authdata

[Marcus Watts]

Elliot Lee <sopwith at redhat.com> writes:
> From: Elliot Lee <sopwith at redhat.com>
> Subject: Seriously abusing authdata
> Message-ID: <Pine.LNX.4.44.0203281232541.10341-100000 at devserv.devel.redhat.com>
> To: kerberos at mit.edu
> Sender: kerberos-admin at mit.edu
> Errors-To: kerberos-admin at mit.edu
> Precedence: bulk
> Date: Thu, 28 Mar 2002 13:03:51 -0500
> 
> The basic problem I'm trying to solve is a dialogue-free way for a party
> to use Kerberos to prove that they said X (non-forgeable signature,
> effectively).
> 
> What I tried doing was getting a ticket with krbtgt/REALM at REALM (typically
> used as the first step in user-user auth), the authdata of which contained
> the public half of a randomly generated RSA key. I know that the authdata
> is making it into the ticket (since the ticket data size is directly
> related to the authdata size). The main problem is being able to decode
> that authdata on the other end (the "client" in user-user auth
> terminology). In user-user auth, is there any way for the "client" to have
> the KDC give it the auxiliary information from the TGT ticket that is 
> normally used as second_ticket?
> 
> I'm perfectly aware that it's possible to write a public-key database
> service or other involve-extra-parties solutions, but those are beyond my
> ability to deploy.
> 
> -- Elliot

You're talking about stuffing an object that is massive in size (very
likely at last 1K in size), and expensive and slow to generate (RSA
keygen), into a krbtgt that is not service specific (ie, everyone has
to pay the price) and is meant to be completely ephemeral and
"of-no-value-tomorrow".

If you're willing to hack kdc to do this, why would you not be
willing to run someone else's key certificate storage thingee and
use that?  Or, even simplier, if you don't mind the issues involved
with ephemeral RSA keys and certs, why not use kx509/kca?  That
uses a stock krbtgt to get a perfectly ordinary x509 cert, which
you can just plug into existing software.  It will even save the
certificate in your K5 ticket cache, so it does everything you wanted
to do with authdata, only, without the extra hassles.  The only pesky
issue kx509 leaves you with is dealing with just what an "expired" x509
cert means, but you've got that problem already as well as
"certification revocation" and online vs. offline processing no matter
what solution you do.

				-Marcus Watts
				UM ITCS Umich Systems Group