Exportable encryption & Kerberos

["Mike Swift (NT)" <[e-mail]>]

> 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.