Subject: RE: Exportable encryption & Kerberos

From: "Mike Swift (NT)" <[email-masked]>
Date: Fri, 16 Jan 1998 10:58:32 -0800

I agree that the words "domestic" and "exportable" were poor choices - how
about "strong" and "weak", so that there are no doubts about what is being
offered? I thought about extending the AP request to include additional enc
types. However, negotiating both a key & and encryption type at the same
time is difficult - the thing to do might be to expand the key in the AP_REQ
to be a sequence of keys, and the server replies with they key it chose or
its own key. 

Any support for distinguishing between strong & weak encryption is by its
very nature incompatible - clients and servers that only do weak encryption
have to fail requests to and from machine that do strong encryption, so
extending the AP request structure might be reasonable.

- Mike

> -----Original Message-----
> From:	Ken Hornstein [SMTP:[email-masked]]
> Sent:	Tuesday, January 13, 1998 12:07 PM
> To:	Mike Swift (NT)
> Cc:	[email-masked]
> Subject:	Re: Exportable encryption & Kerberos 
> 
	...
> 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

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Sat, 17 Jan 1998 00:40:32 -0500

From: "Mike Swift (NT)" <[email-masked]>
   Date: Fri, 16 Jan 1998 10:58:32 -0800

I'm still not convinced this is a good thing to put into the protocol
like this.  What if the government decides six months from now that 40
bits is pathetically weak, and allows us to use 48 bits instead?  What
if France requires us to use 16 bits of keying material?  Do we put yet
another hack into the protocol for that?

There is substantial consensus within the IETF that we should not
compromise our protocols for the sake of meeting the requirements of
some transient national government's regulations with respect to export
control.  The IETF, after all, is an International standards body, and
if the U.S. government wants to cripple the ability for U.S. companies
to sell competently written, secure products outside the U.S., that's
the U.S. government's problem.  

This question came up with IPSEC, and when we took a straw poll at the
open IESG meeting, the overwhelming consensus by the IETF engineers was
that we should not compromise our protocols in this fashion.  Hence, in
order to compliant with IPSEC and IPV6 you MUST support strong crypto.
If you do not, you cannot call yourself compliant with those standards.
Companies in the E.U. are free to develop and market IPSEC software with
strong crypto to the E.U., and there are companies that are doing
precisely that.  U.S. companies who don't like this restriction in where
they can market their software are encouraged to lobby the
U.S. government to fix this, and to not bother trying to lobby the IETF
to bless a technically incorrect design choice.

In any case, because of this strong consensus within both the IETF and
the IESG, I have no doubt that any attempt to try to standardize
insecure crypto will be rejected by the IESG.  So I believe it's really
a waste of time to pursue this any further.

Indeed, my big worry right now with respect to Kerberos is that 56 bits
of DES is not strong enough for anything really serious, and that we
should be moving to 112 bit triple-DES keys ASAP.

						- Ted

---

From: Mike Eisler <[email-masked]>
Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST)

> insecure crypto will be rejected by the IESG.  So I believe it's really

The most recent TLS draft has "exportable" cipher suites in it. If nothing
else, I would hope IESG is consistent in its treatment of the output from one
WG versus another.

> a waste of time to pursue this any further.

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.

	-mre

---

From: [email-masked] (Johan Danielsson)
Date: 18 Jan 1998 09:08:56 +0100

Mike Eisler <[email-masked]> writes:

> Without some written definition of weak cryto, what will happen is
> various implementers will implement non-interoperable schemes.

I almost find this a feature. It is more obvious to people that they
are buying crap software if it doesn't interoperate with anything
else.

/Johan

---

From: Mike Eisler <[email-masked]>
Date: Mon, 19 Jan 1998 07:21:20 -0800 (PST)

> are buying crap software if it doesn't interoperate with anything

You and I have the same technical opinion regarding 40 bit privacy, but the
reality is that there is a proven market for it: the United States.
Most U.S. residents use 40 bit encryption in their web browser, even though they
don't have to. I wonder if 40 bit web browsers are similarly popular in other
countries.

	-mre

---

From: [email-masked] (Johan Danielsson)
Date: 19 Jan 1998 20:54:30 +0100

Mike Eisler <[email-masked]> writes:

> Most U.S. residents use 40 bit encryption in their web browser, even
> though they don't have to.

Yes, but doesn't SSL have standardized support for using weak crypto?

> I wonder if 40 bit web browsers are similarly popular in other
> countries.

I would say that 0 bit web browsing is far more popular. Those that
actually use SSL for something real, either use a local strong crypto
proxy, or use some other device as a complement, SecurID or similar.

/Johan

---

From: [email-masked]
Date: Tue, 20 Jan 1998 22:07:49 -0500

Date: Sat, 17 Jan 1998 10:13:14 -0800 (PST)
   From: Mike Eisler <[email-masked]>

   The most recent TLS draft has "exportable" cipher suites in it. If
   nothing else, I would hope IESG is consistent in its treatment of the
   output from one WG versus another.

TLS has an optional "exportable" cipher suite, which standardized
existing practice.  The mandatory-to-implement cipher suite in TLS does
use crypto that takes longer than two hours to break.

We have indeed standardizing existing practice before; most notably in
the ONCRPC specs, where we documented an existing scheme which has the
unfortunate property of taking 45 minutes of CPU time to break all
possible keys used in that particular system.  However, that's different
from standardizing a new protocol extension which uses weak crypto.

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.

						- Ted

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Mar 1998 23:36:28 +0100 (MET)

> 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: [email-masked] (Johan Danielsson)
Date: 06 Mar 1998 04:27:10 +0100

Martin Rex <[email-masked]> writes:

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

This is exactly what you don't want. Weak keys should be clearly
labeled as such.

/Johan