proposed IPSEC changes/extensions

[Stephen Kent <[e-mail]>]

Folks,

        In working with Ran on revisions to the ESP and AH documents, I
also looked at the IPSEC architecture document.  I'm suggesting several
changes or extensions to that document, to better specify what it means to
be a compliant IPSEC implementation.  The following items are indicative of
the sorts of material I would like to include in a revised IPSEC
architecture document.  I am soliciting comments from the WG on each of
these points.

Required Protocol (header) Support

       The document explains the need to support AH and both transport and
tunnel modes of ESP, based on the context (host vs. security gateway).
However, what about nested combinations of these protocols?  It probably is
not reasonable to require an implementation to support all possible
combinations of these headers, nested to any depth.  I put forth the
following list as a starting point for this discussion: AH, ESP (tunnel),
ESP(transport),
AH-ESP(transport), AH-ESP(tunnel), ESP(tunnel)-AH,
AH-ESP(tunnel)-ESP(transport), and ESP(tunnel)-ESP(transport).

        Note the nested ESP and AH/ESP configurations allow for termination
of one SA at a security gateway, with an embedded SA going to a host.
Because ESP can offer integrity & authentication as an independent option
(i.e., without confidentiality), use of AH must be carefully examined as it
is no longer the only way to provide these services.  Perhaps this list is
too long, and we can pare some of the combined AH/ESP support requirements.


Required Management Parameters

        I have expanded upon the list of required management support
parameters.  Rather than note only the new ones, I've included the whole
(revised) list.  Pay attention to the notes on what system class must
support what management parameters.  One set of management parameters I
propose adding extends the granularity of SAs, in both directions, to allow
for both fine-grained SAs (at gateways and hosts) and coarse-grained SAs
(primarliy for inter-gateway use).

        - Authentication algorithm and mode being used for AH or ESP.
          [REQUIRED for all implementations].
        - Key(s) used with the above authentication algorithm
          [REQUIRED for all implementations].
        - Encryption algorithm and mode used with ESP.
          [REQUIRED for ESP implementations]
        - Key(s) used with the above encryption algorithm.
          [REQUIRED for ESP implementations]
        - Presence/absence and size of a cryptographic synchronisation or
          initialisation vector field for the encryption algorithm.
          [REQUIRED for ESP implementations]
        - Authentication key crypto period (fixed future time or duration).
          [REQUIRED for all implementations].
        - Encryption key crypto period (fixed future tie or duration)
          [REQUIRED for ESP implementations]
        - Lifetime of this Security Association
          [REQUIRED for all implementations]
        - Destination IP Address of the Security Association; this may be
          a wildcard address if more than one desitnation system shares the
          same Security Association (behind a security gateway)
          [REQUIRED for all implementations]
        - Source IP Address(es) of the Security Association; this might be
          a wildcard address if more than one sending system shares the
          same Security Association with the destination
          [REQUIRED for all implementations]
        - Replay Protection information, including whether it is in use,
          information on the window size for the sequence numbers, etc.
          [REQUIRED for all implementations]
        - Sensitivity level of the protected data (e.g., in IPSO terms)
          [REQUIRED for all systems claiming to provide multi-level
          security, RECOMMENDED for all other systems]
        - Next Protocol (from IP header) as an optional SA selector
          input for outbound traffic
          [OPTIONAL for contexts that require fine-grained SA management]
        - Source and/or Destination TCP/UDP Ports as an optional SA
          selector for outbound traffic
          [OPTIONAL for contexts that require fine-grained SA management]

        Also, the current text calls for userID as a required input to SA
selection in a host.  However, this precludes some implementation options,
e.g., bump-in-the-stack and external hardware implementations.  I'd suggest
we relax or reword this requirement to permit a wider range of compliant
implementations.

AH & ESP Document Changes

        The goal of the AH and ESP document changes is NOT to modify the
syntax of the protocols.  Instead, the revised documents will consolidate
the formats that have arisen in various extensions, to avoid proliferation
of transform specification document. The changes for AH are very minor,
i.e., it will be described as a base protocol with an optional anti-replay
field and associated processing semantics.  Support for anti-replay would
be mandatory.

        For ESP, the changes are much more significant.  The protocol
(header) will consist of a set of optional, mostly variable-length fields,
each of which is selected at SA establishment to describe the specific
security services desired for the SA.  The optional fields include an IV,
sequence number for anti-replay, and an integrity check value (in addition
to the static SPI and next protocol fields, and the padding).  Thus there
are no new fields (not already described in some existing tranform) nor
substantive changes in processing description. (We've been talking about
compression for a while, more so recently, but I don't know if there a need
for any new fields for this, rather than just an SA characteristicto be
negotiated?)  Support for all of these fields would be mandatory.  The set
of algorithms supported is separate from this document and support for
specific algorithms (really sets of algorithms) is separated from this
document.

        As above, I solicit comments/suggestions on this proposed approach
to revising these doucuments (already in progress).

Steve