[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Open issues for inline keying.
I've gotten several bits of feedback on my inline keying proposal;
unfortunately, there doesn't seem to be any particular consensus in
the comments I've received.
Please read draft-ietf-ipsec-inline-isakmp-00.txt; it's not very long;
a quick summary is that it involves "spawning" new security
associations from old ones by using "reply-SPI-creation" messages
piggybacked on normal network traffic.
I see three major open isues:
Issue 1:
How do we frame the reply-SPI creation message within the packet?
[There are some similarities between this issue and the compression
issue. It would be good to resolve them in a similar way..]
option 1a:
Steal a bit out of the ESP encoding to indicate the presence
of a reply-SPI-creation message. Perhaps the next-to-the-high-order
bit of the pad length? :-)) This bit would only be used if the
endpoints had configured/negotiated inline keying in the parent SA.
option 1b:
use a new IP-level protocol with a "next-protocol" field, and
set the next-protocol field of the containing ESP header to this new
protocol, and the inline-keying protocol's next-protocol to the
payload's protocol. One implementor was significantly opposed to this
idea; another was significantly in favor of it and I haven't heard any
other opinions.
option 1c:
Use the ipv6 "destination options" IP-layer protocol (IP
protocol 60) to contain the reply-SPI-creation message.
For those unfamiliar with ipv6 (which includes myself): ipv6 doesn't
include any space for option information in the base IP header;
instead, it uses a nested protocol approach akin to AH (ip protocol 60
is the "ipv6 destination options" protocol). It appears to me that
there is fundamentally no reason why this protocol could not also be
used inside an ipv4 header, though it may be a little more work in
ipv4-only implementations and it may complicate mixed ipv4/ipv6
implementations.
option 1d:
anyone have any better ideas?
Issue 2:
What goes inside the reply-SPI creation message?
option 2a:
An a message from an ISAKMP quick-mode exchange (which
requires three messages before both new SA's can be brought up).
option 2b:
A simplified quick-mode-like message which creates a reply-SPI
in a single message, allowing both child-SA's to be brought up in a
single message exchange, probably piggybacked on the SYN and SYN-ACK
of a connection establishment.
This is lower overhead, probably higher efficiency, but more
work to implement and analyze since we can't just encapsulate the
isakmp message and send it in line.
Issue 3: Keying the payload which is along for the ride with the
reply-SPI-creation message.
option 3a:
Just use the SPI's encryption as-is [which seems like it might be
cryptographically weaker than options 3b and 3c ]
option 3b:
Include a nonce in the reply-spi-creation message to hash with the
shared secret to generate the key for this packet. [this is
effective, but non-modular]
option 3c:
define a new class of ESP transforms which include a nonce in
each packet (Hilarie Orman called this a "key hash index") which is
combined with the SA's shared secret to generate the key used to
encrypt the packet. This may be easier to do given the new
mix-and-match ESP architecture which Steve Kent has proposed, and I
think this, without the additional reply-SPI-creation protocol, is
what Hilarie is looking for.
---
Does anyone have any commentary? If you have a preference, please
explain why (since I'm easier to convince if there's a rationale
behind it).
I am currently leaning towards 1c, 2b, and 3c, but could be convinced
one way or the other. The -01 draft will likely continue to waffle
about the issues unless I receive *convincing* arguments in favor of
particular options by late tomorrow.
- Bill