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

Re: compare-jfk-sigma.txt

Concerning ...

> From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
>     Markku> Policy is what gets handed down to you by a person (or a system)
>     Markku> responsible for the security of the site or service you want to use
>     Markku> and which is protected by IPSEC.
>   You've described an intra-organizational VPN.

and ...

> From: Henry Spencer <henry@spsystems.net>
> Assuming that both you and the site/service you want to use are
> under the same administration.

How an earth did you end up with this conlusion (VPN/same
administration)? I must try to express myself once more...

Preamble...

 - I'm only discussing about matters related "Phase 2" SA's. I'm not
   concerned with Phase 1 SAs

 - my claim: phase 2 SA negotiation does not require and should not
   include the selector information. It does include the SA fields
   present in SAD in RFC-2401 sense (but these have nothing to do with
   "policy" in my terminology).

I assume a host has a policy database which is maintained by the USER
of the host. This user decides what policies apply to his/her host!

For example,

   if there is a web server (= 10.0.0.1) that requires ESP (3DES) to
   access the pages, then user *ADDS* the following line to the policy
   database

            remote=10.0.0.1, remote_port=80
	       => use ESP (3DES, remote_port, local)

   and the server host would have the following policy line (no IP
   address required, anything to port 80 needs IPSEC)

            local_port = 80 => use ESP (3DES, local_port, remote)

   The 'local/remote_port' and 'local/remote' are flags which tell
   what information from the triggering packet is to be present in the
   resulting SA. I'm decoupling the SA template specification from the
   selector specifation. You could have line

            protocol=tcp =>
	       use ESP(3DES+SHA1, local_port, remote_port)

   which would negotiate a separate SA for each different TCP
   connection.

If the same user has a POP or IMAP mailbox on some other or on same
server host, he would just add the appropiate selector lines with the
stated policy requirements into his policy database.

If the same user, in addition, need to use VPN connections from
different administrations, he will just add the new selectors to the
local policy data.

Having the selector information in the phase 2 negotiation just adds
complexity, and is *TOTALLY* unnecessary for the functioning of
IPSEC. The policy *IS* fully enforced by the kernel SPD (as per
RFC-2401).

The only consequence of the selector information is interoperability
problems and limitations, how selectors can be defined.

> From: Henry Spencer <henry@spsystems.net>

> There is also the desirability of checking for errors.  Even under a
> common administration, just because the two ends are *supposed* to
> agree on security policy does not mean they do, and a silent failure
> of agreement can result in no communication and no clear indication
> of why.

So far, this is about only useful thing that might result from the
passed policy information in phase 2 SA. HOWEVER, I think the same
result would be achieved in much simpler way:

  - don't use selectors in phase 2 negotiations,

  - instead, have a notification payload, that can be used notify
    about the problem A host noticing that it is dropping packets
    from some host due to policy rule, could send this notification
    with appropriate information, if it has phase 1 SA for that
    host.


Finally, above only concerned the policy relating to the phase 2
SA's. This is simple. The true difficulties are in transfering the
required information for establishing the phase 1 connection. They are
much more complex, including the public keys and so on.

What I would like to see, for example, extending the web server
example:

  enable "pay for use" (or otherwise restricted) access web
  server. You would need to base the phase 1 negotiation on possesion
  of server certified private key, without any binding to clients
  current address. When ISAKMP (or whatever) can do this, things will
  get interesting. People could buy/or be given "access rights" to the
  server.

-- 
Markku Savela <Markku.Savela@iki.fi>
Follow-Ups: References: