Subject: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Mon, 12 Jan 1998 16:31:08 -0800

> The current Kerberos protocol does not support exportablity very well -
> there is not a convenient way to negotiate the strength of a key between
> the client and a server. For large scale deployment and shipment of
> internationalized products, this is a requirement. In the latest draft of
> the protocol specification, the following is proposed:
> 
> To make this example more concrete, ifthe encryption method in use
> required a 56 bit key, and for whatever reason,one of the parties was
> prevented from using a key with more than 40 unknownbits, this method
> would allow the the party which is prevented from usingmore than 40 bits
> to either propose (if the client) an initial key with aknown quantity for
> 16 of those bits, or to mask 16 of the bits (if theserver) with the known
> quantity. 
> 
> However, it may be impossible to tell from inspecting a key how strong it
> is - if salting is applied before a later modification, then a 128 bit and
> a 40 bit key may appear similar. There are a couple of possibilities on
> how to address this problem. Rather than sending a true key, a new
> encryption type could be created that send just the keying material, which
> would then be converting on either side into a key. The length of the key
> material could be used as an indicator of its strength. Another
> possibility is to introduce new encryption types for exportable
> encryption. Both these possibilities require new encryption types, and the
> AP request structure does not allow for easy negotiation of what
> encryption types are supported.
> Instead, I propose that one of two things: either a new flag be added to
> the AP request that indicates that the client wants export strength
> encryption, or the keytype field of the key itself be used to indicate
> that the key is export strength. The advantage of the adding an AP request
> flag is that if current servers ignore the flag and don't modify the
> subsession key supplied by the client, they may continue to work with an
> exportable client. 
> There are four cases of domestic/exportable clients and servers to
> consider.
> 
> DOMESTIC CLIENT, DOMESTIC SERVER
> In this case, the client may propose a sub-session key. If the server
> doesn't respond (this is not mutual auth) then the client's sub-session
> key will be used by the server. If the server does respond, it may also
> propose one in response, which will then be used by both sides.
> 
> EXPORT SERVER, DOMESTIC CLIENT
> The client may or may not propose a key. If a flag indicating the key is
> export strength is not sent, then the server will either generate an
> export strength key for mutual-auth, or fail the request. It will also
> return a flag indicating that the key is export strength. The key
> generated by the server will be used by both sides. In this case, the
> server is assured it is using an exportable key, while the client has to
> trust the server that the key is the appropriate strength.
> 
> EXPORT CLIENT, DOMESTIC SERVER
> The client will generate an export strength key and send the flag
> indicating it is export strength. If there is no reply, the key will be
> used. Otherwise the server must either send back the same key in the reply
> or send no key in the reply. The client-generated key will be used by both
> sides.  In this case, the client is assured it is using an exportable key,
> while the server has to agree to use the key that is the appropriate
> strength.
> 
> EXPORT CLIENT, EXPORT SERVER
> The client will generate an export strength key and send the key and a
> flag indicating it is export strength. The server must trust that the
> client generated a true export-strength key and not a stronger key. The
> server responds as in the case of a domestic server.
> 
> This model allows the code to use either domestic or export strength keys
> but forces the server to trust that the client generated an appropriate
> key. Without creating new encryption types it is difficult to do
> otherwise.
> 
> Any comments are appreciated.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 13 Jan 1998 15:04:20 -0500

The IETF is about engineering, not politics.  Crypto export control is
a political problem, not a technical one.

There's nothing to stop anyone outside the borders of the US from
implementing full-strength crypto, and there's nothing which requires
folks outside the US to buy their crypto from inside the US.

Therefore, there's a workaround to the political problem which doesn't
require weakening the strength of the protocols; the export control
laws only really affect the profitability of US companies.

I object to any attempt to weaken the (already overly weak) crypto in
Kerberos.

						- Bill

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 13 Jan 1998 15:06:40 -0500

>> encryption types are supported.

Could you elaborate on this more?  It seems like Section 3.2.6 of the
latest revision will do what you want ... am I missing something?
(Entirely possible :-) ).

On further reflection, I think I understand what you mean ... you can
only propose one key in the subkey field of an AP_REQ, which kinda limits
your choices.

Maybe the thing to do is make the AP_REQ have an optional list of
enctypes for the server to choose from?

The only thing I don't like about your proposal is the use of "domestic"
vs "exportable"; as someone else pointed out, this is pretty US-centric.
And what do you do if the law changes? :-)

--Ken