[2855] in Kerberos
RE: export question
daemon@ATHENA.MIT.EDU (kaufman@zk3.dec.com)
Tue Oct 12 20:01:45 1993
To: Jim_Miller@suite.com
Cc: kerberos@MIT.EDU, kaufman@zk3.dec.com
Date: Tue, 12 Oct 93 19:37:15 -0400
From: kaufman@zk3.dec.com
>A significant difference between
>KRB_PRIV and "authorization data in a ticket" is that the authorization data is
>first sent to the TGS in the clear, and only then gets encrypted. (I say "sent
>in the clear" because I'm assuming that we dealing with a Kerberos mutation
>that has no KRB_PRIV message type.) The government types who worry about
>encrypted user data could theoretically capture the "authorization data" when
>it was initially sent from the client process to the TGS. This *might* (big,
>hugh, enormous might) satisfy the ITAR requirements:
>
>Anyone care to speculate whether the initial cleartext transmission of
>"authorization data" to the TGS would satisfy the ITAR requirement that you
>cannot export a system that has the "capability of maintaining secrecy or
>confidentiality of information"?
I'm game to speculate, but not without a spate of disclaimers...
Export control is a black art. It is true that Digital received export
approval to ship a hobbled version of Kerberos V4 that had user data
encryption removed. It was also recoded in parts to in-line crypto
code, it was shipped in binary form only, and it was packaged with
other software in a particular way that may or may not have been
relevant to the approving authorities. Someone else asking the same
question might have gotten a different answer. We might have gotten a
different answer had we asked on a different day. I claim it is
impossible to accurately predict what will be acceptable and what will
not. There are, however, things that appear to increase the odds of
getting export approval and things that appear to hurt such chances.
That said, in my relatively uneducated opinion it would not help your
case much to assert that authorization information passes from the
originating node to the KDC in the clear before passing encrypted to
the destination. That first hop is likely to be local and not as easy
to tap as the second.
There are other ways you could hobble the implementation, however, that
might help you. In any given environment, the authorization data is
likely to be highly structured. If the API to the user were to not
permit supplying arbitrary data but only data that met some format
criteria that only let the user code a small number of bits of
information in a large package of bits, that would probably help. It's
conceivable that the encoding of authorization data within tickets with
the performance hassles of talking to a KDC would make it acceptable
without any restrictions. Remember the goal of export control is to
prevent practical encryption schemes from being deployed. If it's so
cumbersome that no one in their right mind would use it for encryption,
it might be OK.
It's certainly the case that the V5 designers could have done would-be
exporters a favor by signing the authorization data instead of
encrypting it. The same effect could be achieved by sending
authorization data as a separate part of your protocol and sending only
the MD5 hash of the data as Kerberos authorization data (of course that
wouldn't interoperate with other implementations that did it the other
way, but use of the authorization field in Kerberos V5 does not yet
appear to have been standardized except in the context of OSF DCE). An
implementation that let the user supply data to be signed as
authorization data would probably pass muster.
btw... authorization data is not the only problem with Kerberos V5.
Kerberos V5 defines delegation by acquiring a ticket or TGT for a
server and then passing that information along with the validating key.
But since it provides no special purpose routines for passing the key
to the server encrypted, you can't use it without the encrypt user data
function. This could "probably" be fixed by introducing a special
purpose routine that requests such a delegation ticket and encrypts it
all in one glob.
Good luck. Stay out of jail.
--charlie
(kaufman@zk3.dec.com)
