Elliot Lee <[EMAIL PROTECTED]> writes:
> From: Elliot Lee <[EMAIL PROTECTED]>
> Subject: Seriously abusing authdata
> Message-ID: <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sender: [EMAIL PROTECTED]
> Errors-To: [EMAIL PROTECTED]
> 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@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
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos
