[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed IPSEC changes/extensions
Steve, thank you for the effort. A few comments and questions below.
Pau-Chen
on Mon, 28 Oct 1996, Stephen Kent wrote
>
> 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).
Q: By AH-ESP (tunnel), do you mean the final output of encapsulation will be
IP-AH-ESP-IP-... (AH is done after ESP) or
IP-ESP-AH-IP-... (AH is done before ESP) ?
>
> 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]
Q: What is the difference between "crypto period" and "SA life time" ?
What do you mean by "crypto period" ?
C: Related to the above question, if you mean "key life time" by
"crypto period" and allows the keys(s) in an SA to be refreshed
after the "crypto period" expires. Then I have some comments :
Key refreshment is definitely needed. However, my experience tells
me there will be trouble if, in concept, we refresh only the key and
not the SA; unless the SPI of the SA is changed together with the key.
The reason is that, in practice, you need a short period of overlap
between the old and new keys. Otherwise, there may be disruption of
communication whenever a key expires. If the old and new keys are assigned
the same SPI, then the receiver will have trouble knowing which key to
use during the overlap. This could either cause false security alarm
(because the wrong key is used) or double the processing cost (trying
both keys).
C: If "crypto period" or "SA life time" is an SA parameter, should they be
negotiated by key management protocol ? Perhaps as an attribute of a
transform in ISAKMP ?
> - 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]
C: If the wildcard is only for the security gateway case and the SA's
terminate on the gateway, then it may better to just record the exact
end points in SA's and let the gateway's policy determines which system(s)
an SA should be applied to.
> - 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]
C: The "protocol" and "port" attributes seem to intervene with a system's
secuirty policy. In practice, a policy can say multiple
<address (range), protocol, port numer (range)> tuples will use an
SA. My experience tells me that it is much easier to implement such
policy as rules in a table than as attributes in SA's. I would suggest
to mention fine-grained policy can be implemented using some "binding"
between SA, protocols, ports and addresses but leave the exact binding
mechanism to the local implementation.
>
> 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
>
>