[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Inline SA Bootstrap protocol
Hello, all
An off-topic section
--------------------
I see many people worldwide being involved in the ipsec
discussion. I will greatly appreciate if someone familiar
with US law clarifies (via direct reply) the legal aspects
of ipsec contribution by non-US people in form like this
memo. The difference (if any) to do this as not employed
person (like me now) vice an employee working for non-US
company would be helpful as well.
Thank you in advance.
Abstract
--------
This memo proposes so-called Inline SA Bootstrap
scheme. The inline SA bootstrap protocol allows
create/re-key/synchronize particular SAs at the cost of
(possible) exposure of Key Identifiers. The scheme is
explained here based on the reference to the known SKIP-07
draft.
Bill Sommerfeld, the author of the ...inline-isakmp-01.txt
might want to inspect this memo for using the idea of SKIP
protocol number (and it header) for inline SA bootstrap
under ISAKMP protocol.
Thank you, Bill, for valuable systematization of the
questions to be addressed to inline SA setup problem. Hope
that you might use some tips presented below during
further development of your spec.
The memo is, as well, an attempt to bring SKIP protocol
on the list of RFC 1825-conformable and it serves for further
development of this specification.
The memo is sent to both ipsec and skip-info mailing lists
and can be converted into one, two or zero drafts
depending on your, folk, interest.
Introduction
------------
This memo employs some of Bill Sommerfeld ideas, such as
- Sending inbound SA SPI with the first packet of the bi-
directional connection.
- Implicit acknowledgement about a SA creation and
inclusion the requested SPI value right in the backward
traffic of particular connection.
This memo defines in-band keying header format and
proposes the framing model for inline SA setup protocol.
Proposed scheme differs from Bill's by staying independent
from ISAKMP/Oakley protocols and by using ESP/AH headers
themselves to carry in-bound SPI value(s).
The proposed scheme can be used for bi- and unidirectional
traffic and might simplify such things as SA recovering
and re-keying procedures.
Most important security aspects are covered herein as
well.
Core idea
---------
Suppose that two communicating parties use DH-type public
keys for IPsec communication. If these DH keys are
authenticated and assigned with identifiers, the parties
can safely calculate shared secret based on DH algorithm.
To setup particular SA the parties now need a context that
includes at minimum:
- Starting and Destination points of a SA.
- Optional tunneling addresses.
- Key ID of an Initiator.
- Key ID of a Responder.
- Core SA attributes, such ESP or AH protection,
tunneling or transport mode and specific transforms
identifiers.
- SA session key.
- SA scope, such as the IP protocol, source and destination
ports.
- SPI values (to be selected by a network data
receiver).
Assume that other SA attributes such as replay protection
window, SA lifetime, etc can be assigned with default values.
Let's propose the following framing of inline SA context.
a) All but IPsec specific attributes are to be derived
from native IP datagram.
b) All security related attributes are derived from just
introduced SA inline context header being included in the
IP datagram along with optional application data.
c) Some SPI values are to be reserved for carrying the
inline SA protocol signals.
To simplify things with SA inline header structure, the
SKIP header format has been selected for scheme
demonstration. Fortunately, SKIP header format contains
all attributes required for the proposed protocol. The
SKIP header will be referred to as SA_INLINE_CONTEXT
hereinafter.
Note: I'm not introducing here a new inline SA context
header format to not enter in the discussion about it
completeness and proven security (just trying to let
already developed stuff serve people better ;-).
In short, the Inline SA signals can be encoded with the
help of reserved SPI values placed into ESP/AH headers
following the SA_INLINE_CONTEXT header.
For example, during normal SKIP operation the ESP/AH SPIs
found there are set to reserved SKIP_SPI==1 constant as
indication on SKIP as keying material source. Keeping
it as is, let's introduce one more reserved SPI value ==
FORWARD_SA_REQUEST to serve as a command to convert
SA_INLINE_CONTEXT framing into the plain ESP/AH.
Having met with the FORWARD_SA_REQUEST SPI value along
with SA_INLINE_CONTEXT header, a responder must consult
with local security policy and, if it not refuses the
proposal perform:
- Create a SA template.
- Select desired SPI value.
- Send an Acknowledge with include SPI value back to the
initiator.
Upon getting the ACK receipt, the initiator fixes SPI
value for unidirectional traffic and starts sending pure
RFC 1825 packets (i.e. without SA_INLINE_CONTEXT header).
Upon receiving the first packet of plain ESP/AH format,
the responder fixes SA template to become just normal SA
context.
An initiator might want to request two SAs at once for
bidirectional traffic when it sends inline SA request
described above.
It can be done by an initiator with the following
algorithm:
- Create forward SA template.
- Create backward SA template.
- Select SPI for the backward SA.
- Send this SPI value instead of the FORWARD_SA_REQUEST
one as a request for creating two SAs at once.
In that case, the responder will acknowledge both SAs by
sending ACK signal to the initiator.
Thus, for bi-directional traffic two SAs can be created at
the cost of only two packets roundtrip. If the inline SA
request packet contains both ESP and AH headers, then two
forward and two backward SAs will be created.
In turn, all the transactions above additionally can carry
an application data like FTP, NFS, PING, etc.
Note: If SA_INLINE_REQUEST does not employ MAC transform,
the extended scheme must be used instead of this
simple one.
(See Re:Hiding party identifiers and other stuff)
A number of critical issues do arise with the proposed
scheme, consequently:
1. The format of ACK packet.
2. Tolerance to replay attacks.
3. An inline SA Re-keying Procedure.
4. Hiding party identifiers and other stuff.
5. Interaction with ISAKMP or other Key Management
application.
The resolving of these issues extends the inline SA
bootstrap scheme with additional data structures and adds
extra logic to the protocol itself.
Re: The format of ACK signal
----------------------------
Now, it's a time to reserve one more SPI value called
FORWARD_SA_ACK. The algorithm to construct the SA ACK
packet by the responder is as followed:
- Create SA_INLINE_CONTEXT from the one containing
FORWARD_SA_REQUEST SPI value.
- Use Destination Key ID from the original
SA_INLINE_CONTEXT header as Source Key ID in the new one.
- The same is for Source Key ID from the original
SA_INLINE_CONTEXT header.
- Generate random packet encryption key and encrypt it
using long-term shared secret between initiator and
responder.
- Set SPI value(s) in the new SA_INLINE_CONTEXT to have
reserved FORWARD_SA_ACK constant(s).
- Place the IP protocol number in the NEXT field of
ESP/AH header.
- Compose the inner datagram derived from the received
FORWARD_SA_ACK packet as per examples below:
Received Request packet format:
[Original outer IP],
[Original SA_INLINE_CONTEXT (SKIP)],
[ESP (SPI= FORWARD_SA_REQUEST, Next = TCP)],
[Encrypted TCP header, Encrypted TCP data]
[ESP trailer][Opt MAC Data]
Sent ACK packet format:
[Outer IP header]
[Constructed BACK_SA_INLINE_CONTEXT],
[NEW_ESP (SPI= FORWARD_SA_ACK, Next = IP)]
[Original outer IP],
[Original SA_INLINE_CONTEXT (SKIP)],
[ESP (SPI= responder-assigned SPI, Next = TCP)],
[DECRYPTED TCP header, OPTIONAL TCP data]
Above example shows an ACK on created transport mode SA,
next is for ACK on tunneling SA request.
Received inline SA request packet format:
[Original outer IP],
[Original SA_INLINE_CONTEXT (SKIP)],
[ORIGINAL_ESP (SPI= FORWARD_SA_REQUEST, Next = IP)],
[Encrypted inner IP header],
[Encrypted TCP header, Encrypted TCP data]
[ESP trailer][Opt MAC Data]
Inline SA creation ACK packet format:
[Outer IP header]
[Constructed BACK_SA_INLINE_CONTEXT],
[NEW_ESP (SPI= FORWARD_SA_ACK, Next = IP)]
[Original outer IP], [original SA_INLINE_CONTEXT (SKIP)],
[ORIGINAL_ESP (SPI= responder-assigned SPI, Next = IP)],
[DECRYPTED inner IP header],
[DECRYPTED TCP header, OPTIONAL TCP data]
The remaining steps are:
- Encrypt/Authenticate NEW_ESP datagram according to the
BACK_SA_INLINE_CONTEXT rules
- Send resulting packet to the initiator
Note 1: Information presented in the scope of ORIGINAL_ESP
header of ACK packet is not encrypted, so does not comply
with respective RFC! If it seems inappropriate, a IP protocol
type has to be introduced.
Note 2: OPTIONAL application data can be just excluded,
since remaining fields serve as comprehensive selector for
the SA template saved on the initiator side.
Note 3: The original outer IP header, the decrypted inner
IP header and the decrypted application protocol header
must be sent back unmodified. Even the IP checksum and
length fields!
Note 4: The described ACK signal must not carry any
application data sent by an application to the responder
side.
Implicit ACK signal
-------------------
When an initiator wants to request both forward and
backward SAs, he selects backward SPI and sends it inside
the inline SA request packet. A receiver of such packet
treats the presence of non-reserved SPI value along with
SA_INLINE_CONTEXT header as a request to create SAs for
both directions. This case works only when both parties
are ware that an application on responder side will
definitely reply upon the receiving first packet from the
connection initiator.
This reply is generated, in turn, not by IPsec itself, but
by an application and serves as implicit acknowledgement on
the backward SA creation as well as carries the SPI
value for the forward SA requested of the initiator.
All backward packets must always include SA_INLINE_CONTEXT
header until the initiator will start sending plain
RFC1825 datagrams. The exact operation modes and algorithm
identifiers for the backward SA are chosen by a responder.
Re: Tolerance to replay attacks
-------------------------------
Well, this very important issue must be always considered
when implementing described protocol.
First proposed replay protection scheme works under the
following assumptions:
a) SA_INLINE_CONTEXT implements coarse grained replays
protection
b) An implementation caches all SPI values proposed by
remote systems during the period, when SA_INLINE_CONTEXT
replay protection mechanism does not work.
c) An implementation must silently drop all SA requests
and ACK packets having SPI values found in cache.
Fortunately, SKIP protocol employs coarse-grained replay
protection besides one-hour time interval. If SAs
establishment rate is two per second, the cache must
support 2*3600=7200 SPI entries.
Note 1: Replayed Acknowledgments can be recognized within
protocol state machine.
Note 2: An implementation must not produce the same SPI
values within two hours interval.
First scheme won't work in case when machine has been just
rebooted, so the SPI cache is lost. It can be reactivated
based on facts:
a) At least one 'right' SA has been established by the
remote node.
b) The current IP-ID value of the remote IP implementation
has been captured upon completion of (a).
c) The ID counter of IP datagrams sent by the remote
node is expected to be monotonically increased within
some predefined window.
Second replay protection scheme works independently from
the first one. In addition, it can be used to catch the
fact (a) mentioned above at the cost of dropping
application data sent in the inline SA requests. Dropped
packets either will be reposted by an application or do
not have much value.
In short, for unidirectional inline SA requests, the
algorithm for the responder is:
- Send generated SPI value and ACK packet as usually,
but block application data from being passed upstream.
- If 'old' SA for the requested IP protocol and ports
exists, continue to accept traffic on it.
- Continue apply above techniques for all further
requests.
- Fix new SA only when received and successfully
checked first packet of plain ESP/AH format that
employs generated SPI in effect.
- Delete 'old' SA if it exists.
For bidirectional inline SA requests apply:
- Create two SA templates, but do not activate them.
- Continue accept data sent under 'old' SAs (if any
exists).
- Continue drop application data found in inline SA
requests.
- On each inline SA request continue send generated SPI
value along with ACK packet from within ipsec engine.
- Wait for the first successfully received packet of plain
ESP/AH format.
- Activate both SAs.
Summarizing this section, to successfully prevent
replaying attacks under inline SA bootstrap protocol an
implementation must either always support SPI values cache
or employ extended scheme done at the cost of possible
losing some IP datagrams.
Re: An inline SA re-keying procedure
------------------------------------
The proposed protocol allows change current keys on the
fly. If a party wants to change the session Key for
particular SA, it sends inline SA requests as described
before. The receiver of such requests must create new SA
context and reply with new generated SPI value. Upon
protocol completion, old SA is destroyed.
Note 1: If an initiator sends proposal on re-creation the
backward SA as well, the responder must either spawn
corresponded outgoing connection into separate SA or
refuse entire request.
Note 2: It is possible design inline SA error notification
similar to the ACK packet format at the cost of one more
reserved SPI value.
Re: Hiding party identifiers and other stuff
--------------------------------------------
Although the inline SA bootstrap protocol makes the SA
context visible to eyedropper it can be improved at the
minimal cost for an implementation. The way to get
additional security is encapsulation of inline SA
bootstrap packets.
For the host ipsec implementation the SA initiator likely
will be a user who wants get access to secured resources
of remote server (responder). IMO, the server must have at
least one well-known and authenticated Public-Key identifier.
Otherwise, even ISAKMP cam meet definite problem to setup it
master SA the right way.
The most important thing here seems to hide identities of
the SA initiator (i.e. user).
Following this goal, a SA initiator generates DH key
(under SKIP SA_INLINE_CONTEXT case) and composes the
following inline SA request packet:
[Outer IP]
[SA_INLINE_CONTEXT (generated Key ID-i, known Key ID-r)],
[ESP (SPI=SKIP_SPI, next header = SKIP/IP)],
{
[Optional IP header],
[SA_INLINE_CONTEXT (original Key ID-i, any Key ID-r)],
[ESP (SPI=FORWARD_SA_REQUEST/BOTH_SA_REQUEST, next
header = IP],
{{[Inner IP, application data]}}
}
{:} Bracketed data are protected based on generated Key of
the initiator and well-known key of the responder.
{{:}} Bracketed data additionally is protected by original
Key of the initiator and any from Keys of the responder.
Since the outer SA_INLINE_CONTEXT contains just SKIP_SPI
value, a responder will not try to complete inline SA
bootstrap protocol on it.
However, the responder must send an ACK packet under
additional protection of the received, outer
SA_INLINE_CONTEXT header.
Generated Key ID must be cryptographically bundled with
generate Public Key. For example, so-called UDH
certificate format as per SKIP drafts proposes using of
MD5 hash over DH Public-Key and other attributes. A
party can retrieve this certificate via online request to
the remote node.
Re: Interaction with ISAKMP or other Key Management
application.
----------------------------------------------------------
Inline SA bootstrap scheme can work together with any Key
Management application and provide benefits both for KM
application functionality and overall system security.
For example, the ISAKMP situation includes possibility of
negotiation a SA context using protocol/port wildcards.
However, it is not possible add/delete particular
connection to/from SA context without reestablishing entire
Security Association. With inline SA bootstrap protocol,
one can provide fine runtime tuning the explicit set of
protocols/ports, which are bundled to specific SA.
Next issue comes from SA re-keying procedure. If the
encryption key lifetime set say, to 512Kb of transferred
data, the re-keying procedure may take place every 0.5 sec
for 10Mbits-network carrier. From other hand, if 600 SAs
were established for a long period and the encryption key
lifetime was set to 5 min, the re-keying procedure needs
to be applied as well twice per second regardless of
underlined network bandwidth. In turn, one SA re-keying
will take two SPI delete/create operations.
With using inline SA bootstrap, parties, if won't to
expose their identifiers, can negotiate fictive IDs to use
in the SA_INLINE_HEADER when changing their session key.
The parties need not enter in the mutual authentication
each time the key will be changed.
A message for SKIP people
-------------------------
IMO, SKIP protocol remains valuable alternative to the
session-oriented Key Management since it stays closer to
stateless IP network protocol nature. Whenever the
unreliable datagram scope is considered as critical
environment to operate on, SKIP provides the best
performance/reliability characteristics. However, it does
not fit into RFC 1825 requirements. Consequently, it needs
further development of it basic specification as well as
various extensions, which will make independent
implementation more robust and interoperable.
By the way, in the official IETF drafts archive SKIP
specification is marked as obsolete. Moreover, it text is
no more available for downloading. For this reason, could
someone answer following questions?
- Is it still on the public domain?
- Will SUN keep it in the list of proposed IETF
standards?
- If above is yes, is there any author who will take
care about development of the next version, is it possible
to contact him?
A message for all ipsec-oriented folk
-------------------------------------
To date plenty companies have done implementation of core
IPsec engine. However, most of them employ only shared
secret management capability. With using inline SA
bootstrap scheme it would be possible design extended SA
management even staying only with shared secret keys. It
is easy to see that INLINE_SA_HEADER can carry an index of
that shared secret and SA context information to perform
requests for particular SA management without entering in
complicated application level KM negotiations.
If the whole scheme will not be compromised by you, ipsec
people, it can be used successfully for many things, which
currently are marked as "TBD" in the respective drafts.
I have found following areas:
- The discovering security gateways
- The synchronization of lost ISAKMP state
- The ability to have multiple master ISAKMP SAs
established between the same parties
- A SA negotiation via a proxy party
- The support for broadcast and multicast IPsec
communications
Most of the above mentioned schemes can be implemented at
the cost of additional reserved SPI values and with using
the same framing model.
Let me know, if possible, your opinion.
Regards,
---
Alexei V. Vopilov (alx@elnet.msk.ru), +7(095)5367694
Software Architecture & Development Consultant.
---
Follow-Ups: