Re: Exportable encryption & Kerberos

[[e-mail]]

Item Subject: Exportable encryption & Kerberos
     The proposed scheme does provide additional information, but it does 
     not address the problem of clients and servers with different crypto 
     capabilities interoperating.  Having either the client or server 
     blindly trust the other presents problems. A rogue could force the use 
     of crypto that is too weak or too strong for a particular environment. 
      
     
     It would be desirable to have a client that is capable of both strong 
     and weak crypto.  There are several types of servers the client may 
     interoperate with.
     
     1. Generic server -- the client must use weak crypto
     2. Approved Server -- the server has characteristics (such as key 
     recovery and key escrow) that allow for the use of stronger 
     cryptography.
     3. Approved Sever in an Approved Institution -- the institution which 
     is using this server is approved for stronger crypto.
     
     It is therefore essential that the client have a means of identifying 
     the cryptographic allowances of the server it is talking to.  I 
     believe there is an SSL mechanism in practice that allows for a 
     special certificate to be returned by the server to the client which 
     proves that the server can use stronger crypto (If someone could point 
     me to the details of these "special certificates" I would be 
     grateful).  Current proposals in kerberos could be used in a similar 
     way to help with this problem.
     
     The current PKINIT proposal allows the server to return a certificate. 
     This certificate could provide the assurance of the capability to do 
     stronger crypto.  However, this only identifies the KDC which may be 
     sufficient for meeting government regulations in case 3.  It may cause 
     problems with case 2 because there is no guarantee that the 
     application server is participating in key management.  In this case I 
     do not know of a specification to return a certificate from an 
     application server (I don't think either PKTAPP or PKDA apply), one 
     would probably have to be invented.  
     
     I'd appreciate any comments on this, I am coming from a US point of 
     view.  The CAT working group may not be the best place to focus on 
     these issues.  If there is a better forum let me know.  The problem of 
     cryptographic restrictions is much broader than US export regulations. 
      
     Joe Salowey
     WRQ Software
     [e-mail]
     


______________________________ Reply Separator _________________________________
Subject: Exportable encryption & Kerberos
Author:  mikesw ([e-mail]) at internet,shar
Date:    1/12/98 4:31 PM


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