Subject: Re: Exportable encryption & Kerberos

From: [email-masked]
Date: Tue, 13 Jan 1998 14:46:58 -0800

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
     [email-masked]

______________________________ Reply Separator _________________________________
Subject: Exportable encryption & Kerberos
Author:  mikesw ([email-masked]) 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.

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Fri, 16 Jan 1998 11:08:55 -0800

I agree that my suggesting is not the ultimate for negotiating encryption.
The current Kerberos AP protocol does not allow for much negotiation,
unfortunately. I hesitate to start relying on something like PKINIT for
everyday operations - it adds a whole new layer to the already complex
enough setup for Kerberos.

The solution I propose does allow for upgrade and downgrade attacks by rogue
servers & clients. I'm not too worried about downgrade attacks because a
client or server can always just expose the information. As for an upgrade
attack, only servers are vulnerable because the client would get to choose
the key in this case. The only way around this that I know of is for either
a new encryption type to be defined or for a standard way to inspect a key
and tell how strong it is, neither of which seem practical.

- Mike

> -----Original Message-----
> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Tuesday, January 13, 1998 2:47 PM
> To:	Mike Swift (NT)
> Cc:	[email-masked]
> Subject:	Re: Exportable encryption & Kerberos
>

---

From: Richard Salz <[email-masked]>
Date: Sat, 17 Jan 1998 21:24:07 -0500 (EST)

> An Informational RFC on 40 bit
>Kerberos V5 privacy would be useful for that reason.

If the members of the IETF decide it's useful to standardize emasculated
crypto to ensure interoperability, then I hope we'll all be very blatant
and define things such that the "naught bits" (n>41:) are sent in the clear
by the protocol(s) in question.  In no way should this be sugar-coated.
	/r$

---

From: [email-masked]
Date: Sun, 18 Jan 1998 19:11:37 -0800 (PST)

>by the protocol(s) in question.  In no way should this be sugar-coated.

        Damn right!  Bell, whistles, popup windows, and bad smells wherever
available should be used to alert the user and clearly indicate that the
encryption being used is very very weak.

        Could the WG or the IESG mandate such an overt warning in the
implementation?  Maybe with an explicit recommendation that the user seek
to negotiate more secure crypto with his correspondent(s) ...if possible
and legal, and if he or she requires more than minimal protection for the
confidentiality and integrity of the transmitted data?

        That would be neat for several reasons -- not least of which
because it would maybe let J.S. and the IESG and/or the IAB go head-to-head
with the US govt. directly.

        And that, in turn, might get the user and the vendors out of the
line of fire and lessen the temptation of various IETF activists to scorn
useful _Interoperability_ standards -- which seem to necessarily reference
(and require, for universal connectivity) the weak crypto which is the
strongest the feds allow to be freely exported by US-based vendors.

        That new banker's suit becomes you, Mr. Salz.
        ;-)
   Suerte,
                     _Vin