Subject: Re: Exportable encryption & Kerberos

From: [email-masked]
Date: Fri, 6 Mar 1998 09:06:52 -0500

Martin writes:

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

If there's any logic at all to the export restrictions (and I know
that that's a big if), they'd have to require weak encryption in
both directions, because allowing strong encryption in one
direction enables strong encryption in both directions.

If you allow a strongly encrypted channel from A->B, then A & B
can easily conspire to create a strongly encrypted channel from
B->A by having A generate a random key-stream, send it to B over
the strongly-protected A->B channel, at which point B simply XORs
his data with the key-stream and sends the results back to A.

I think you'd be extremely lucky if you were to get an export
ruling that allowed this.

John

---

From: "Mike Swift (NT)" <[email-masked]>
Date: Wed, 11 Mar 1998 11:49:02 -0800

This is the approach I'm currently taking - I've defined a bit in the key
type to indicate that it is a weak key. Rather than introducing new
encryption types, I prefer the approach of introducing a new key type that
indicates that the key is weak. I tend to think that introducing new
encryption types isn't necessary - just a new keytype indicating that the
key is weak.

As Sam points out, we also need to define the semantics associated with weak
keys. If the client proposes a weak key, the server needs to either respond
with the same weak key or fail the connection. Otherwise the client can't be
assured that the server is using a weak key. If the server proposes a weak
key, the client needs to either use that key or fail the connection.

- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, March 10, 1998 4:31 PM
To: David Margrave
Cc: [email-masked]
Subject: Re: Exportable encryption & Kerberos

David Margrave <[email-masked]> writes:

> Some possible options for discussion:

Neither of these are acceptable. If you necessarily have to
standardize on something it should be clear to all involved parties
that a key is weak. Under no circumstances should a weakened key be
used without clearly marking it as such. I suggest that some wording
to this effect be added to 1510++.

To move this discussion forward I propose the following. The etype of
an EncryptedData is an INTEGER, which with current implementations
give us a maximum of 32 bits. The possible values for this field are
defined in section 8.3 "Protocol constants and associated values". I
propose that this integer instead should be interpreted as a
`bit-field' looking something like:

specification	bits
--------------------
type		10
mode		10
checksum	10
weak key	 1
new format	 1

Type is an encryption type like DES or DES3, mode is which particular
mode should be used, like CBC or CFB, and checksum is the checksum to
use. Some of these values could be common to all encryption types, and
other could be specific (this could be done via some internal
structure in these fields). The weak key flag should be set if the key
has been weakened in any way. The highest bit specifies that this is
an encryption type of this new type.

The new value for des3-cbc-sha1 might then be 0x80A00402, indicating
checksum type 10 (SHA1), mode 1 (CBC) and encryption type 2 (DES3).

This is compatible with old clients, and old KDCs (if the clients send
both new new and old enctypes). This does not solve the problem of
knowing which enctypes the server supports, but this is something that
has to be handled by the application protocol anyway (or by something
like the crude support-md5 hack in the MIT KDC).

It also makes it possible to both emit and reject weak keys (either by
explicitly looking at the weak key bit, or by just not recognizing the
enctype).

/Johan

---

From: "Linn, John" <[email-masked]>
Date: Thu, 12 Mar 1998 09:04:18 -0500

I wrote, excerpting:

> I'm not sure at this moment whether there's an
> established higher-level precedent on this issue (but will try to find
> out), but consider this a broader-scope policy question than can be
> resolved within the CAT (or any other) WG.
> 
I checked with Jeff Schiller, the Security AD, on this question.  He
pointed out that there's been a premise informally called the Danvers
Doctrine, dating back to the plenary session at the IETF meeting  held
at that location in April 1995, establishing a general principle that
the IETF will not standardize facilities for "export-grade"
cryptography.  Also, RFC-1984 sets out the IAB/IESG position on several
cryptographically-related policy topics, including but not limited to
this issue.

--jl