[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SKIP and key management lower module alternatives
Hello All,
Assuming the approach to key management can be a modular one,
I would like, if possible, to have the opinions of people from the list, as to
the nature of the lower level module.
As I see it, there are two possible approachs,
1) Encrypted key as key ID: This is the method adopted by SKIP.
In this approach an encrypted packet key is carried in the packet.
2) Short key ID: The short key ID is part of the SAID, that appears in the
IPSP header. The key ID can serve as an index to a key table.
The SKIP approach is connection less. In this sense it is very IP-oriented. Key
refreshment doesn't require handshake.
An additional advantage it has, is that it is indeed very simple. Only the
encryption keys used to encrypt the packet key has to be managed, and there
is no exchange of key IDs.
As I see it, SKIP has three main disadvantages:
1) Security weaknesses : there are several issues raised in an e-mail sent
by Hugo (8-Nov-94).
In SKIP a shared master key, under which the packet key is encrypted is
established once, and never changed. Most of the issues raised by Hugo
can be avoided, if SKIP is extended by adding a higher level interactive
protocol for master key refreshment.
2) Space overhead : each packet size is enlarged by at least 8 bytes.
3) DEC patent: As mentioned in a e-mail Amir sent (15-Nov-94) Digital holds
a patent on using an encrypted key as a key identifier, see Charli Kaufman's
attached mail as to a relevant patent.
In the short key ID approach, the SAID contains a key ID, which serves as
an index to a key table. This approach doesn't have the above disadvantages,
but on the other hand, it doesn't have the simplicity and the elegance of
the first approach.
I'll appreciate getting opinions, as to which approach is more suitable for the
IPSEC purposes,
Thanks,
Sara Bitan
RadGuard LTD.
Israel
972-3-6459592
----- Begin Included Message -----
>From ipsec-request@ans.net Mon Aug 8 21:57:48 1994
To: ipsec@ans.net
Cc: atkinson@itd.nrl.navy.mil, amir@watson.ibm.com, kaufman@zk3.dec.com
Subject: Encrypted Key Patent
Date: Mon, 08 Aug 94 17:57:48 -0400
From: kaufman@zk3.dec.com
X-Mts: smtp
Content-Length: 4601
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)
----- End Included Message -----
!