[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Encrypted Key Patent

There has been some confusion around a patent Digital holds on using
an encrypted key as a key identifier.  As one of the guilty parties
having filed the patent, I'd like to try to clear it up.


Reference:

Patent #5,081,678 filed 6/28/89 issued 1/14/92: "Method for
Utilizing an Encrypted Key as a Key Identifier in a Data Packet in a
Computer Network".


Q: What is patented: 

A: The technique of encrypting a session key under a per-node
private master key and putting that encrypted key in the packet header.


Q: Why would anyone want to do that??:

A: As Phil Karn pointed out, this consumes
network bandwidth by having a large (8 bytes) key identifier when a small
one (1-2 bytes) would do with no obvious savings.  We needed to do it because
of a particular type of cryptographic hardware we built.  We wanted the
hardware to be able to decrypt packets as they arrive off the net before they
enter the node's memory.  The conventional way to do this is to have a key
table in the hardware looks up keys based on a key-id (or connection id) in
the packet header.  Because we didn't want to have enough memory in the
hardware to store keys for the largest possible number of connections, we
came up with putting the encrypted key in the packet header.  An anomoly of
hardware solutions is that sometimes they can decrypt faster than they can do
table lookups.


Q: And we wanted the IETF to standardize that kludge!?

A: No.  We wanted the IETF standard to permit it.  Almost any protocol is going
to have some sort of key identifier in the packet header.  We needed two
things:
	1) For the key identifier to be allowed to be large enough to
	hold an encrypted key.  That's 8 bytes for DES and more for
	better algorithms.

	2) For the key establishment algorithm to permit the destination
	to specify the key id to use rather than having one somehow
	selected algorithmically.  This is useful in other contexts as
	well; a conventional implementation, for example, is likely to
	want the key identifier to be a small integer used to index into
	a table.  For best use of memory, it would like that integer
	to be chosen from a dense space.


Q: So is this on the standards track now?

A: Sort of.  We had proposed a variable length "SAID" that could hold the big
key identifier.  It was pointed out that this data need not be in the
SAID, but rather could be in the algorithm-specific header.  Since we
aren't yet debating algorithm specific formats, the debate has effectively
been postponed.  Since this has to be settled before we can actually
build things that interoperate, I hope it will come up again soon.


>From: Ran Atkinson <atkinson@sundance.itd.nrl.navy.mil>
>
>> Note- DEC has patented this clever technique.
>
>I'd like to put out a request and reminder since there are many on this
>list who are somewhat new to the IETF way of doing things.
>
>1) The IETF normally tries to avoid using patented techniques in IETF
>specifications, though it is not always possible (sigh).
>
>2) In any event, it is ALWAYS important to note ALL possible
>intellectual property claims relating to any proposal in the FIRST
>note or presentation of the proposal.  It is not good practice to
>propose a technology which is subject to intellectual property claims
>(e.g. patents) without that up front disclosure.
>
As noted above, it is not necessary or even useful for the standard to
prescribe use of the patented technique, so I don't think that is an issue.
I was up-front about mentioned the existence of the patent when I
proposed the formats.  At issue is to what degree should the IETF go
out of its way to accomodate a technique that is not freely available.
Clearly, the answer is not very far.  I don't think it needs to, but
reasonable people will differ on how far is too far (and unreasonable
people will flame).
>
>However clever one might consider the DEC technique, I don't want to
>include it in any portion of the standards-track specification UNLESS
>DEC formally agrees in writing to license it to all comers at no cost.
>
I'm sure Digital's policy is the same as that vague one quoted from
IBM about reasonable, non-discriminatory, etc. etc.  There was a time
when we might have been willing to sign up for free licenses to grease
the path through standards.  Today, this effort has a much lower priority
and I wouldn't know how to motivate someone with the authority to do this
to spend the time to think about it.  I continue to advocate this approach
because I think it is sound engineering that someone may take advantage of
someday.

	--Charlie
	(kaufman@zk3.dec.com)