Subject: Handling of krb_error checksums

From: Sam Hartman <[email-masked]>
Date: 23 Jan 2002 15:33:47 -0500

We briefly discussed krb_error checksums at the working group and I
indicated I would get back with a more detailed proposal.  Here is
that proposal.  I believe this is the right direction to go, although
it does complicate the krb_error message a bit.

There are three places in the protocol where krb-errors can be
generated: in response to AS requests, in response to TGS requests and
in response to ap-reqs.

We believe we can provide general criteria for when to sign these
errors.  First we want to avoid signing a request when we aren't sure
what key to use for the signature.  Clients are very likely to ignore
errors with checksums that do not match, and this is to be encouraged
so creating situations where clients receive bad checksums because the
server guessed what key to use and guessed incorrectly is a bad idea.
Secondly, we want to avoid making it too easy to mount known-plaintext
attacks especially against long-term keys.  We certainly must not
mandate that a checksum be created in a long-term key when the server
would have been unwilling to encrypt text in a long-term key for a
successful request.  Similarly we want to avoid forcing an
implementation to sign an error in a long-term key when the request
failed because preauthentication should have been provided to avoid
exposing the long-term key.

Whithin these constraints though we want to require errors be signed
whenever possible to avoid DOS attacks.  Thus the KDC needs some
mechanism to communicate preauthentication back to the client so the
client can know what key to use to verify the error.  Currently we
have such a mechanism for preauthentication required errors, but we
need to extend that mechanism.  So we propose that all KDC-REQ errors
need to be able to carry preauth information even if they are not
preauthentication required errors.

Unfortunately this means that krb-error ends up with a lot of typed
holes.  It already has edata.  This preauth requirement means that we
add a hole to carry preauth data to every error other than preauth
required.  We already planned on replacing the use of typeddata stored
in the edata hole with  a typed hole in the message.  

So basically we want to mandate that if the authentication of the
request succeeds (preauth for AS-req, authenticator and checksum
verification for others) and if the server knows what key would be
used for a successful reply, then the error is signed.  IS this the
direction we want to take?

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 24 Jan 2002 09:20:28 -0500

After giving this topic more thought, my opinion is that, since we
can't sign all errors, the only thing that will work to reduce spoof
DoS attacks is either to recommend the use of TCP or other reliable
transports and/or add a return-routability-test pre-auth type as
discussed before.

The latter applies only to KDC exchanges (*), so the former is the more
general approach, but TCP's connection handshake is not terribly strong,
so the rrt pre-auth sounds appealing. I could go either way.

If MIT krb5 had support for KDC exchanges over TCP the point would be
moot for me.

(*) AP exchanges are usually done over TCP anyways.

Cheers,

Nico

--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.