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

Re: Policy question



-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Dan" == Dan McDonald <danmcd@Eng.Sun.Com> writes:
    Dan> Consider that I have a machine that has no specified security preferences.
    Dan> That is, w/o additional per-socket tweaking, outbound traffic goes out in the
    Dan> clear and that inbound traffic is cheerfully accepted in the clear.

  Okay. I will assume for the purposes of discussion that this is a Unix
machine. When you say that you have no specific security preferences, I
assume that this means:
	1. either no-bsd-<1024-port restrictions are in place (that is,
		your rexecd will believe what I say regardless of what
		port I arrive on), or no such services are accepted, period.
	2. your telnetd, if you have one, isn't going to restrict root logins
		from network ports.
	3. you have no tcp wrappers, or other ways of selectively accepting
		network traffic at the application layer.

  In other words, I suggest that "no specific security preferences" goes
beyond whether traffic is encrypted or authenticated. In general, a host has
a set of security policies which are used to determine how much
authentication is required before the host will believe that some entity is
authorized to do some action.

    Dan> Now consider an encrypted TCP SYN that is received by this machine.  For the
    Dan> time being, assume the inbound SA is in place (I'll touch more on this
    Dan> later).  Given the lack of policy constraints I can do several things:

  ...

    Dan> One other thing to consider, which you may have picked up earlier, is that it
    Dan> is possible to have the IKE daemon on this machine deliberately reject all
    Dan> requests for negotiating secure services in this case.  (This means the SYN
    Dan> would never arrive, as the IKE negotiation would fail.)  This is okay, but if
    Dan> only manual keying is being used, you can't have that sort of access control.

  1. manual keys can still have selectors. Perhaps people are unlikely to
  configure per-port SA's with manual keys, but if they configure per-host
  keying, then they are effectively configuring any-port keys. If they don't
  configure a per-host outbound SA as well, then I guess they are saying that
  outbound traffic need not be encrypted.

  2. Ideally, the IKE deamon's permitted policy database can be informed of
  application specific requirements.
  I know that many applications have policies far more specific than can be
  expressed at present with, for instance, the BSD-sockets IPsec extensions,
  or can be communicated by the kernel to the IKE via PFKey. Clearly this is
  a field for a lot of OS-specific experimentation.
  I can imagine ktelnet or ssh-like remote logins via IPsec+IKE. I don't,
  however, expect IKE to read the .rhosts .shosts .ssh/authorized_keys, etc.

    Dan> So what should one do given the above situation?  I suspect my alternatives
    Dan> were ordered least-to-most preferable.  I'd appreciate feedback from the list
    Dan> on this.

  I think your options were artificial since you assumed the inbound SA was
already in place. Clearly, you must have some policy in place. Imagine a busy
web server with your most-preferable solution (do encryption if asked), and
no hardware assist on the encryption... 

   :!mcr!:            |  Sandelman Software Works Corporation, Ottawa, ON  
   Michael Richardson |	SSH IPsec: http://www.ssh.fi/. Secure, strong, international
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>. 




-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBNWCbydiXVu0RiA21AQEqPAMAyoDm9eho1bdpkxZvNov653qa6ht2bBDh
MA5g+AwWcit8+lxXeozI7udb5BRLH9ZEjieLJQFzzJXu4WK6NBZb4prsCXDvpEUG
nhIb24+cSQST3we3bPGAyUmXlckYjhpw
=45p7
-----END PGP SIGNATURE-----


References: