Subject: Kerberos crypto and encrypting with authenticated plaintext

From: Ken Raeburn <[email-masked]>
Date: Thu, 06 Mar 2003 01:36:17 -0500

Many recently proposed modes of operation like CCM support
authentication (in Kerberos context, integrity protection) of additional
plaintext data when encrypting.  This can be used, for example, to prove
that packet headers which have to be unencrypted are in fact associated
with the encrypted payload.

It turns out the Wrap token in the message I mailed out a little while
ago about the GSSAPI krb5 mech is such a case.  If the Kerberos crypto
framework supported this, I could say, "encrypt this application data,
and check the integrity of this additional token header data", instead
of having to duplicate the header fields in the encrypted section, or
compute and send additional checksums.

I looked at the current Kerberos crypto draft, and found that it's very
easy to add this in, actually.  Annotated changes to the text are
attached.  Don't let the size scare you; most of the volume comes from
unchanged context, or paragraph-filling changes.  (Sorry, my version of
diff doesn't seem to have an option to ignore line breaks.)  Making the
changes took much less time than preparing this email.

I think the GSS Wrap case makes it at least as useful as the
cipher-state chaining my co-"conspirators" in the crypto draft work have
persuaded me to keep in.  I know it's kind of late, but I'd like to
consider adding it.  (I've been thinking about it for a while, but until
I was working on this GSS stuff I didn't have a concrete example to
point to.)

I can think of a couple places where we could consider taking advantage
of this in the kerberos-extensions work (do the addresses and sequence
number in a KRB-PRIV really need to be encrypted and not just
authenticated?), but these wouldn't be trivial changes, and unless the
encryption CPU time is a big deal, or we have other significant changes
to make anyways, it's probably not something to spend a lot of time on.

But clearly, as my GSS case shows, Kerberos applications using Kerberos
encryption schemes directly can make use of it.

Backwards compatibility?  No protocol issues; as with cipher-state
chaining, the current Kerberos clarifications draft obviously never uses
this (though we could tweak the draft to make that explicit), and in all
cases an empty authdata string will make no change to the output.
Obviously, implementations may have to get updated if this gets used in
the GSS mechanism, and the GSS mechanism uses the same crypto code as
the Kerberos library.

Complexity?  Yeah, it's a little more complicated, but not much, and
it's a logical extension.

Security?  If there are issues relating to adding known plaintext into
an MD5, MD4 or CRC sum of hidden data, then we should also be worrying
about checksumming ASN.1-encoded messages with some predictable fields.
That's not much of a security "proof", I admit. :-) In the GSS case, at
least, the DES-based encryption types shouldn't be used with the new
Wrap format anyways.

Delaying last call?  The crypto draft isn't quite ready, unfortunately.
As I noted here after sending out the most recent version, there are
still one or two places where weak-key issues need to be settled.
(Unless we want to do a "first last call" without those fixes, to try to
prod a few more people to look at it, even though we know it'll need
another round.)  I hope to have them fixed before or soon after San
Francisco, but since I've already got these changes written up, clearly
the actual editing work wouldn't hold up getting the new version out.

RC4?  That draft could easily have authenticated plaintext added to the
encrypted data over which the HMAC is computed.  Any other stream cipher
proposal is still going to have some MAC added too, so adding
authenticated plaintext ought not to be a problem.

Comments?

Ken
(yawn... enough for now...)

P.S.  As for the revised crypto draft, most of the week after IETF I'll
be on vacation in San Francisco and Seattle.  So if I don't get
something out by the end of IETF, it'll likely be at least a week later.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Mar 2003 15:45:34 -0500

I really think it is too late to add this now.

I do not object in concept to the idea though.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Mar 2003 23:03:13 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> I really think it is too late to add this now.  I do not
    Sam> object in concept to the idea though.

OK, after thinking about this more I believe that I have a better
understanding of why I dislike including this in the framework.

I don't think it is useful unless you mandate that all the encryption
systems support including external authenticated text along with the
encryption system.

The point of the crypto framework is to guarantee a set of facilities
available to applications and the Kerberos protocol provided by
Kerberos crypto systems.-

I don't see how this mode would be useful if it were sometimes
available, and I don't think it appropriate to add to all the existing
crypto systems at this late of date.

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 07 Mar 2003 04:58:38 -0500

> systems support including external authenticated text along with the

True.

> Kerberos crypto systems.-

Kind of.  It's not as if any Kerberos implementation shipping right
now actually supports everything in the current draft, nor does it
need to in order to support Kerberos clarifications or RFC 1964.  The
Kerberos protocol itself doesn't even need everything we've put in.

> crypto systems at this late of date.

You mean like we did with the PRF operation?

"All the existing crypto systems"?  The DES change is in the common
part of the spec, so I'd count that, the simplified profile, and RC4
as three places for very simple changes to be made in existing
cryptosystems.

Ken

---

From: Sam Hartman <[email-masked]>
Date: Fri, 07 Mar 2003 12:15:11 -0500

>>>>> "Ken" == Ken Raeburn <[email-masked]> writes:

    >> available, and I don't think it appropriate to add to all the
    >> existing crypto systems at this late of date.

    Ken> You mean like we did with the PRF operation?

Yes, exactly. In the case of the PRF I felt very uncomfortable but did
not know how to implement several work items without PRF support.

In this case, it is clear how to get along in a reasonable manner
without this support.