[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: