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

Re: Bundle or not in negotiation

> From: Daniel Harkins <dharkins@dharkins-ss20.cisco.com>

> It doesn't really need anything but you have to express your wishes to
> the peer as unambiguously as possible. If your wishes are "protect all 
> these packets with both AH and ESP" but you say "protect all these packets
> with AH" and then at some later time say "protect all these packets with
> ESP" the peer can two things.

This where our views of IPSEC architecture seem to differ
radically. IPSEC does not express a "wish" to key management, it gives
it a command to set up a matching pair of SAs on both end points

    h1   (AH)   h2
   SA1 ------> SA1
   SA2 <------ SA2

The only "wish like" component is, that this command may allow some
alternatives for the encryption/authentication parameters to be used
in this association. The command may succeed or fail.

> He can refuse your AH offer because his policy says he needs ESP in
> addition to AH and you just offered AH ...

No, he cannot refuse on policy grounds. He might on *some* cases know
that the negotiated SA is not usable (doesn't match any local policy),
but why bother, IPSEC will have to check this again anyway, why burden
the key management with duplicating tasks that are already done in
other components?

Consider the policies on SG2 from my earlier example:

>    +============================+
>    |                            |
>    | +========================+ | 
>    | |                        | |
>    | |                        | |  
>    H1* ---- (Internet) ------|SG2* --- (local) --- H3*
> 
 Policies: Selector => Bundle
    @H1:  H1<->local => ESP(3des,sha1), AH(sha1,tunnel=SG2)
   @SG2:  (a) SG2<->internet => ESP(3des,sha1), AH(sha1,tunnel=H1)
          (b) local<->internet => AH(sha1)
    @H3:  H2<->H1 => ESP(3des,sha1)
 
H1 is negotiating AH SA with SG2. When the SA negotiation is
simplified to occur independently, the resulting architecture allows
(if desired) the use this same SA for both (a) and later for (b)
policies. This SA for AH might have been negotiated as a result of
setting up a link to H3 (b) or as a result of setting up a link to SG2
directly (a).

> Even without opportunistic encryptors there can be situations where policy
> has not been configured symmetrically. I could require ESP for packets
> and you require AH and ESP. If you offer ESP to me (assume the first acquire
> you got was for ESP) I'll accept. If you later offer AH to me I won't.
> I'll send you packets which you'll drop. To me we successfully negotiated
> but you're droping my packets.

What I am trying to do, is to put the key management back to its box
(of negotiating single SA pairs) and prevent it meddling (or confusing
itself) with things is has no business to touch or know about, such as
IPSEC policies. [Or, perhaps I am just asking for a new, simpler key
management system, that works with IPSEC (*) :-]

Succesful SA negotiation just means that both ends have the SA
matching the command issued by IPSEC. Packets are dropped until all
the required SAs are present.

If the policies on both ends don't match (for example, specified
different ordering of transforms), there will be no succesful
communication, even if all key negotiations succeeded. Such situation
can be very frustrating to the end user. A good implementation should
try to detect this and give a proper error message. If IPSEC receives
valid packets, that fail on "bundle checking" stage, there is a policy
mismatch. This will be detected on the first received packet after all
asked SAs are in place.

----

(*) speaking of simple key management. I have only manual keys, but I
would really like to have the session keys negotiated, but at this
point I am not really up to writing a full IKE for myself. I wonder it
would be possible write a very simplified, but IKE compatible
application, where most of the exchanges are hard coded, e.g.

 - Assuming a single user host, with a specific userid (perhaps a
   public keys are preinstalled on both ends, no need to
   certificates).

 - have most the packets compiled statically for this special case,
   and just have code to fill in the variable information,

 - whats the mininal number of packets that would go back and forth?
   Three? Does anyone have a skeleton program for such (I can get the
   encryptions stuff from outside USA).

-- 
Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland
Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/
References: