[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
re:On SKIP and non-interactive key management
Here is the second part of my responses to Hugo's comments.
> From: hugo@watson.ibm.com
> What about derivation of multiple keys (e.g., for key encryption and key
> authentication). Should such a scheme support more than one way to derive
> Kij? This would require the specification of this algorithm in the IPSP
> header (adding to the space demands).
What is the benefit of this? If a packet is authenticated, and the
packet key verifies it, doesn't this authenticate the key as well?
Why is there a need to have multiple ways of deriving Kij?
>Data key sharing
>****************
>
>* Attaching keys to each packet.
>The most significant protocol penalty of SKIP is probably the need to transmit
>the data key(s) Kp in each packet. Even if you have most of your traffic
>directed to a single node (or group of nodes) with which you use an unchanged
>Kp for many packets still you transmit this key with each packet. This
>results in 100 or more bits for communicating a redundant information
>(much less bits can do that job, e.g. via a SAID). This significant
>space overhead is clearly undesirable;
The penalty of inline keys is approx 1% of a typical 1024 byte
IP packet.
How much this matters depends on the bandwidth of the networks
on which this is to operate. On very slow links this is a disadvantage.
On fast links, this is less of an issue. I'll note that the *fixed*
header overhead of link protocols like ATM (designed for high-bandwidth
physical links) is ~10%.
For slow links, the combination of SKIP and compression (allowed
in the basic SKIP proposal) will do far better than unencrypted and
uncompressed IP. This is because compression can gain us a factor of
200-300% in space savings, whereas the inline keys only add 2% and
the total IPSP header is approx 6% penalty of a 512 byte packet
(even assuming smaller MTU size for slow links).
>moreover, it "encourages" the
>implementation of shortcuts to alleviate this situation. An example is
>provided by the draft itself that after recognizing the need for both
>data encryption and authentication keys proposes to have one key as the
>prefix of the other (page 7). That's a bad cryptographic practice that
>compromises security and is solely motivated by the above need to alleviate
>the space overhead.
I agree completely that this is a bad idea. However, the reason
is simply inadequate reflection on the issue. This was one of the last
things that I put in the draft, and didn't get to think for
too long about the issue. Soon after I sent the draft, I realized
this was a bad idea, and now I propose a simple fix to it.
Instead of using a subset bits of Kp for encryption, compute
the ICV of the concatentaion of (Kij + Kp) and use the
upper n bits of the ICV. The ICV algorithm is the same
as the ICV algorithm for packet authentication (ICV alg).
This doesn't incur any extra space overhead, and solves the problem
you mention.
>* The transmission of algorithm identifiers and possibly other security
>attributes with each packet adds to the overhead even if these values are
>most of the time fixed for a pair of nodes.
Of course, this kind of argument can be made against an IP header
as well. One can end up arguing in favor of a connection oriented
network protocol like X.25 instead of IP, with this line of
argument. (And precisely some of these arguments were made
by X.25 proponents).
>* The attractive notion of unstructured SAIDs that are decided by the local
>implementation and transmitted to the other party is lost here. Only
>structured, standardized SAIDs make sense.
What is attractive about unstructured SAIDs? I realize the need
for IPSP to allow all kinds of key-management, and hence unstructured
SAIDs, but fail to see anything terribly attractive about unstructured
SAIDs.
The only thing about SAIDs is that they are decided by a receiving
node, and if a receiving node chooses structured SAIDs, and advertises
that in advance, what is wrong with that?
Once again, I'll stop here, and complete the rest of my responses
to the remainder of your comments in another follow-up message.
And again, thanks for the thoughtful comments.
Ashar.