Subject: problem with message integrity of KDC-REP messages

From: "Medvinsky, Sasha (SD-EX)" <[email-masked]>
Date: Wed, 21 Feb 2001 13:59:09 -0500

Currently, the client can only verify the integrity for part of the KDC-REP
message - for EncKDCRepPart only.  In particular, if a man-in-the-middle
changes the contents of the ticket, there is no way for the client to find
out.  Later, the client might get an unauthenticated error from a sever that
says "bad message integrity".  This error code doesn't tell the client that
it is a bad ticket (as opposed to a bad authenticator) and it is not
authenticated and could possibly be a false error code sent by some
attacker.

As a result, due to malicious manipulation of KDC-REP messages the client
might receive bad tickets and never find out that they are bad, not knowing
enough to go back to the KDC and try to get a valid ticket.  Within the
context of PacketCable (VoIP specification that utilizes Kerberos), a client
does not accept unauthenticated error messages from an application server -
so it will not see even the "bad message integrity" error.  

I realize that Kerberos revisions is now on WG last call, but I find this a
serious enough problem (at least in the context of PacketCable) that needs
to be fixed as soon as possible.  There are a number of vendors today that
have either already implemented PacketCable security or are in the process
of implementing it.

After discussing this problem with Matt Hur and Cliff Neuman, here is our
proposed solution:

1) Define an new KDC option in the KDC-REQ:
		7	KDC-REP-INTEGRITY		cleartext portion of
the KDC Reply should include an integrity check

2) Modify EncKDCRepPart to contain an optional kdcrep-cksum field sent only
to a client that requests it with the above option.  This is a plain
checksum over the KDC-REP message encoded without the encrypted part.  Also,
if the KDC doesn't understand this option, it doesn't have to put in this
optional checksum.  

Here is the proposed change to the EncKDCRepPart:

EncKDCRepPart ::=   SEQUENCE {
                    key[0]               EncryptionKey,
                    last-req[1]          LastReq,
                    nonce[2]             INTEGER,
                    key-expiration[3]    KerberosTime OPTIONAL,
                    flags[4]             TicketFlags,
                    authtime[5]          KerberosTime,
                    starttime[6]         KerberosTime OPTIONAL,
                    endtime[7]           KerberosTime,
                    renew-till[8]        KerberosTime OPTIONAL,
                    srealm[9]            Realm,
                    sname[10]            PrincipalName,
                    caddr[11]            HostAddresses OPTIONAL,
	        kdcrep-cksum	Checksum OPTIONAL
}

kdcrep-cksum
	This field should be included in the EncKDCRepPart when it is
requested with the KDC-REP-INTEGRITY option in the KDC-REQ message.  If
KDC-REP-INTEGRITY option was not specified, this field must not be present.
This is a plain (not keyed) checksum over the DER encoded KDC-REP message
without the enc-part field.

---

From: Sam Hartman <[email-masked]>
Date: 21 Feb 2001 16:20:29 -0500

EVen if we do go forward with some change in this form, I believe that
the ASN.1 you propose changing is already being significantly revised
by Tom Yu, and you are inserting fields into the wrong structure.

I also object to any new instances of checksums being introduced into
the data being checksummed.

I have not considered whether solving this problem is necessary; will
do that later.  I'm simply pointing out that if we do choose to solve
this problem, we will have to adopt an alternative solution.

---

From: Ken Raeburn <[email-masked]>
Date: 21 Feb 2001 18:01:45 -0500

(If we want to prevent with malicious attacks that could cause denials
of service, we've got a *lot* of work to do....)

> so it will not see even the "bad message integrity" error.  

And if the bad message integrity error is caused by some other bug --
perhaps a KDC bug, perhaps a MITM between client and server, maybe a
server or KDC configuration error -- do you have the client just keep
retrying until it times out?

> I realize that Kerberos revisions is now on WG last call, but I find this a

Actually, I think we're still in the unofficial section-by-section
last call, aren't we?

> if the KDC doesn't understand this option, it doesn't have to put in this

I think we'd need to redefine KDC-REP then, so that the thing to be
checksummed is actually a valid object.  (Or we can just say, "hey,
we've broken ASN.1 so badly already, it just doesn't matter", but I'd
rather not.)  Either the enc-part field becomes OPTIONAL (but required
for all the messages we actually send), or we make a checksum of the
encoding of a *different* message.

Oh, and a new key usage number would need allocated.

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Feb 2001 11:27:07 +0100 (MET)

> have either already implemented PacketCable security or are in the process

What you describe is a clear flaw of the PacketCable spec and it should
definitely be fixed there!  An error message at that level should ALWAYS
be processed, no matter whether it is authenticated or not.
the processing of non-authenticated error messages should be a trivial
change at exactly one location.  Changing the KDC-REP would require
significant changes in various places.

What you currently fear is a DoS that requires modification of only a
single message, the KDC-REP.  If the KDC-REP was integrity-protected,
the DoS would require one modified message per failure.  If the PacketCable
would process unauthenticated error messages, the DoS would also
require one modified message per failure.

Actually there are countless conceivable DoS with the effort
of one message per failure, most of them don't even require to
capture and modify a real message.

Why do you think it's better to add complexity to KDC-REP instead of
fixing an application flaw?

The other thing is, that working around the application flaw seems to
require more changes than to fix the application, because it will
require replacing all affected KDCs in addition to the PacketCable
stuff.  The workaround is not compatible with the installed base,
i.e. although you replace the PacketCable software, you will not
see the workaround in conjunction with installed base KDCs.

Whether or not it it should be possible to protect the other parts of the
KDC-REQ for any real added value is a different issue.  The particular
DoS that you described should *NOT* be considered a valid reason for
such a change.

Technically the KDC-REP doesn't seem to affect or break any installed
base, it only adds complexity, and it does *NOT* seem to be a very
good fix for your problem.

Personally, I really think that the PacketCable application SHOULD be
fixed even if the Kerberos fanciers here add an option to integrity protect
the stuff in KDC-REP!

-Martin