Subject: FW: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Fri, 6 Mar 1998 07:38:28 -0800

I would like to propose extending the Authenticator structure in Kerberos in
include a list of keys. By placing it at the end existing code should skip
over it (or so I'm told). This would allow a client to propose a number of
encryption types and for the server to choose among them. Currently, the
client can only propose one subkey. This makes it difficult both to
negotiate to a weaker encryption mechanism and to a stronger encryption
mechanism. The general idea would be that the client can propose a set of
keys for different encryption types and the server can respond, in the
AP-REPLY, with either one of those keys, or a new key from the same list of
encryption types.

This would require a new weakened encryption types, which could be
accomplished by sending just a limited number of bits of keying material and
then running that through the string-to-key function (or perhaps an MD5 of
that material) to generate the DES key.

Any thoughts?

- Mike

-----Original Message-----
From: Martin Rex [mailto:[email-masked]]
Sent: Thursday, March 05, 1998 2:36 PM
To: [email-masked]; [email-masked]; Mike Swift (NT)
Cc: [email-masked]
Subject: Re: Exportable encryption & Kerberos

[email-masked] wrote:
> 
>    Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST)
>    From: Mike Eisler <[email-masked]>
> 
>    The practical reality is that these laws exist. Without some written
>    definition of weak cryto, what will happen is various implementers will
>    implement non-interoperable schemes. An Informational RFC on 40 bit
>    Kerberos V5 privacy would be useful for that reason.
> 
> Well, if we're going to do weak crypto, we should at least do it right,
> which means defining a new Kerberos V5 encryption type, instead of using
> the kludge which Mike was suggesting.  (Mike, speaking of which, I need
> to talk to you off-line; the hack you guys are using in NT 5.0 Beta 1 to
> indicate a NTLM string-to-key algorithm with an unregistered,
> undocumented encryption type is *really* not the best way to do
> things...)
> 
> It's not clear wheather or not the IESG will published such an
> Informational RFC, but I do understand the argument that there should be
> one broken way of doing insecure crypto.
> 
> However, we should all note that an implementation can't be called
> Kerberos-compliant unless it implements the mandatory-to-implement
> encryption algorithms --- and this position *is* consistent with the
> stand that the IESG has taken in the past on IPSEC, TLS, etc.

I have no experience with US crypto export and I'm not familiar
with the Kerberos protocol details, but I'm really curious about
the following:

Does the export restriction apply to "encryption" only, or is it
also mandated to restrict decryption to keys that are known to
be weak.

i.e.  if the Kerberos protocol is changed/updated (that is necessary
to accomodate *any* crpyto-export scheme, right?) how about the
possibility to use independent keys for each direction?  So both
peers have the opportunity to specify a subsession key that they
will use for protecting outgoing messages.  An "exportable" peer
would only generate "weak" subsession keys, always send them along
and always use them for protecting outgoing messages.   With this
scheme, you wouldn't even have to tag keys as weak or strong.

Now would you be able to get export approval on software that is
still able to successfully receive information with strong
encryption, but applies only weak encryption itself?

-Martin

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 06 Mar 1998 12:38:15 -0500

> that material) to generate the DES key.

Time and time again, the subject of a weakened encryption type for
kerberos has been brought up here.    

DES is pitifully weak as it is; Why are we bothering with anything weaker?

While I'm not the WG chair and am thus not in the position to judge
the presence or absence of consensus, I think it's been clear from
past discussion that there are very few other members of the WG who
think that this is a good idea.

Can't we just drop the idea?  Vendors who want to implement weakened
methods are always free to, but I don't think the community as a whole
is served by having an interoperable weak encryption method...
we shouldn't be standardizing something which is fundamentally broken..

					- Bill