[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ipsec-secconf-00.txt
I think we're supposed to discuss this on the new policy list, so I've
included a cc: to ipsec-policy@mail.timestep.com. If anyone thinks
otherwise, please speak up; otherwise, please delete ipsec@tis.com from
the recipient list if you reply.
Michael Richardson wrote:
>
> In section 2.1, you write:
>
> > Entirely out-of-band configuration represents a seemingly trivial
> > case, although this process could be compromised in various ways.
>
> How could it be compromised?
> Section 3.1 doesn't really tell me much more. It seems to me that this
> situation is when you get the device, you plug into a serial port and/or
> attach to a mgmt network port, and configure things. The comments about
> securing the device during delivery (if this is done at the factory) seems
> justified though.
Section 3.1 notes that the config server could be compromised by
installing hostile software. This hostile software could be a modified
version of the config software, or it could be a shim which intercepts
(and perhaps modifies) socket-layer communications, or it could be a
rogue process, or a rogue driver, or it could be <fill in the blank
depending on the OS>.
Section 3.1 also notes that the device which is to be configured, if not
secured from the point of manufacture to the point of installation, is
subject to device substitution or firmware replacement. This probably
should be made more clear, but means to point out that with no security
precautions, you could be getting a device which has been intercepted
and somehow preconfigured or otherwise modified. We can flesh this
entire section out a bit more.
> Section 5.1 (on SNMPv3) needs to be expanded, and probably needs to borrow
> or reference specific discussions in the SNMP initial configuration
> debate. The SNMP WG archives are *full* of this stuff.. start around june
> 1996 :-)
>
Yes, there are a number of areas in the doc which need expansion and/or
discussion. That's why it was released to the community while
incomplete.
> I think that the best (network, network) configuration method involves
> having a vendor owned key pair that goes into the firmware. You can do
> whatever initial IP, etc. stuff you need to get online, but to actually
> get the configuration saved, or examine any of the trusted store, you
> need to have a certificate, signed by your vendor, attesting to the fact
> that you own this box. This implies that the boxes need to have serial
> numbers in the firmware as well: but since this doesn't have to be a shared
> secret, it can easily go on a bar-coded label that gets processed by your
> shipping department.
This is one of several cert mechanisms which will be included in a
coming document rev, and I agree that it presents a good balance between
security and convenience.
References: