[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Move TS to optional (RE: Don't remove TS from IKEv2)

At 10:03 PM +0200 3/26/02, Markku Savela wrote:
> From: "sankar ramamoorthi" <sankar@xxxxxxxxx>

 Another alternative worth considering is to do policy change
 inband to ipsec traffic.

NO! NO! You cannot change policy from IKE.

There is some serious misunderstanding about what policy is.

In my view policy can never be changed as a result of IKE
negotiation. That would be a huge security hole.

Surely you are not suggesting something like if, I have

selector -> require ESP with 3DES

IKE negotiation could change this into

selector -> allow data in clear

!!!

Apparently other people include into policy what I would just consider
SA parameters (which look like selectors). These parameters are used
to distinguish different SA's between same nodes.

This is related to text "4.4.1 The Security Policy Database (SPD)"

-----------------
            ....  For each selector, the policy entry specifies how
   to derive the corresponding values for a new Security Association
   Database (SAD, see Section 4.4.3) entry from those in the SPD and the
   packet (Note that at present, ranges are only supported for IP
   addresses; but wildcarding can be expressed for all selectors):

   a. use the value in the packet itself -- This will limit use
      of the SA to those packets which have this packet's value
      for the selector even if the selector for the policy entry
      has a range of allowed values or a wildcard for this
      selector.

   b. use the value associated with the policy entry -- If this
      were to be just a single value, then there would be no
      difference between (b) and (a).  However, if the allowed
      values for the selector are a range (for IP addresses) or
      wildcard, then in the case of a range,(b) would enable use
      of the SA by any packet with a selector value within the
      range not just by packets with the selector value of the
      packet that triggered the creation of the SA.  In the case
      of a wildcard, (b) would allow use of the SA by packets
      with any value for this selector.

And in "4.4.3 Security Association Database (SAD)"

   ....
   For each of the selectors defined in Section 4.4.2, the SA entry in
   the SAD MUST contain the value or values which were negotiated at the
   time the SA was created.  For the sender, these values are used to
   decide whether a given SA is appropriate for use with an outbound
   packet.  This is part of checking to see if there is an existing SA
   ...
-----------------------

That is, the negotiated values are put into SA, not into SPD. There is
*NOTHING* in IKE negotiation that needs to be put into SPD!

As the author of this text, let me try to clarify a few things:

- the term "policy" is used in many ways by many folks. high level security policy is usually expressed in natural language and thus is not suitable as a basis for automated enforcement in security technology. low level security policy is directly enforceable by such technology, and that is what the SPD represents. One could imagine an intermediate form of policy expression, which may be (I'm not sure) what IPSP addresses. in any case, I think the use of the term "policy" is appropriate for what the SPD does.

- the symbolic selector values that are permitted in the SPD are intended to represent IP address selectors, with the intent that they be transformed into transient SPD entries, as well as SAD entries, as a side effect of the IKE exchanges. It's clear that symbolic values cannot be directly matched against packet headers, yet 2401 mandates checking against such headers for both outbound and inbound SA traffic. In the rev of 2401 we will introduce the notion of an SPD cache, and using that model, we will do a better job of describing how a symbolic value in an SPD entry is transformed into an SPD cache entry, rather than talking about a transient or temporary SPD entry. I think this will clarify what we envisioned.

- since the above example does involve (under the current 2401 description) dynamic modification of the SPD, I would not argue that such modification is prohibited by 2401. IPSP has discussed dynamic modification of the SPD as a result of a policy negotiation, so that notion is embraced by others as well. I would like to see a way to deal with these sorts of protocols as we progress, in a fashion consistent with the revised 2401 model we're developing, and I solicit suggestions on how to do this.

Steve