Re: [spam score 5/10 -pobox] draft-jones-opsec-01.txt comments

[George Jones <gmj@pobox.com>]

[...continued...]

> > > ``2.11.6 Ability to Maintain Accurate System Time'' should talk about
> > > spoofed timeservers
> >
> > Wording ?
>
> Maybe something along the lines of ``If network time synchronization
> is used, an attacker may be able to manipulate the clock unless
> cryptographic authentication is used.''

I'll add that as a warning.

>  Or perhaps there should be a
> requirement to support authenticated network time.

See

  2.12.12 Support Device-to-Device Authentication

but this one needs work and may be moving to the info side.

>
> The problem, though, is that as far as I can tell, authenticated
> network time isn't always available.  (This is why I wrote an
> internet-draft that tries to explore exactly where Kerberos depends on
> secure network time, and why I have advocated making Kerberos less
> dependent on time of day; I don't think mumbling ``cryptographicly
> authenticated time synchronization'' and pretending that this will
> magically solve all of the real-world issues


No, it won't.   You're refering to operational/topology/availability issues.
All we're saying here is that we want to ensure that the capability is present
in each network element.

> If you limit how much you allow your clock to change on the basis of
> data you get from NTP, and don't allow the clock to be set backwards,
> and don't allow large forward leaps, and have a fairly accurate clock,
> the amount of trouble an attacker can cause is fairly small.
>
> If you care about accurate time for logs, it may be that you really
> need a hardware clock that's designed to be accurate enough that you
> don't need to rely on network time sync much, so that you can
> configure the device to drop time sync if there's any significant
> drift (maybe more than 1%?).
>
> A requirement that the allowed drift be configurable and default to
> something strict might also be desireable, but that seems like it goes
> in the future directions and not BCP draft.

Sounds like you've got enough here for an RFC :-)

> > > and cryptographic authentication.
> >
> > See
> >
> >   2.1.1 Support Secure Management Channels
>
> Oh, OK.  It is at least *there* if I read it carefully enough.
>
> I had been assuming that ``management channels'' meant ``channels to
> enter configuration data''.  Apparently it also means logging and time
> sync.

Yes.


> Apparently a device which allows me to run insecure NTP over a
> management-only IP network

Or TLS, or IPsec, etc. in-band.   I'll update the examples list in 2.1.1
to give specific protocols, inband/out-of-band/etc.

> I'm realizing that because there are multiple options in 2.1.1, it's
> easy in general to get devices which technically qualify but might not
> fit easily and wel into a particular topology.

Possibly.

>  I'd be tempted to
> argue that devices should be required to support doing everything
> in-band if so configured.

The requirement varries according to situation....that's why it
just says "secure management" and allows both in and out of ban.

>  It's hard to do logging and time sync well
> across a traditional serial console port.

Time synch, I'll give you....but I've seen ASR33s, DECWriters and old
PCs hooked up to serial lines that do a fine job of logging on
serial interfaces.

> It might make sense to say
> that if a device has a management IP port, that it MUST support
> logging and time sync on that interface.
>
> I also wonder if there should be a requirement that devices that can
> support more than two IP interfaces MUST or SHOULD allow any interface
> to be configured as a management-only interface.  Though maybe if you
> can turn forwarding off on that interface and bind services to
> specific interfaces, that's kind of sufficient for that or
> something.

I think so.  You have the building blocks.


> But again, I wonder if anyone really uses independent IP management
> networks.

I know of at least one (that drove some of these requirements).

---George