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

[George Jones <gmj@pobox.com>]

On Wed, 17 Sep 2003, Joel N. Weber II wrote:

Sorry for the delay...I'll blame a hurricane and weekend for
3 days of delay...the rest is me being slow.

> I'm having a bit of trouble envisioning a topology where I'd really be
> confident that a TTL-based approach really is the right thing,

"right thing" != "only thing".  Its one tool.

Try this:

    +--D
    |
M-S-+--D
    |
    +--D

H = Management Host (accessed by dialup, ssh, other secure channel)
S = Switch
D = Devices, allowing only only TTL 255

 and
> that the problem couldn't be better solved by controlling bindings.

Yes.

> > The working assumption is that the operator can secure the management
> > device that is directly connected.  Should that be stated ?
> > The security of the devices that are connected is beyond the scope.
>
> I'm not entirely clear on what this paragraph means.
>
> It's certainly the case that every Cisco router I've ever seen has the
> property that you really don't want to plug its console port into
> something which is insecure, but if we're discussing TTLs, we're
> discussing IP.

Either way, serial or IP, it is assumed that directly (or remotely)
connected management devices are secure....at least their security
is beyond the scope of the draft.

> > > Under ``2.2.2 Use Strong Encryption'' it may be worth discussing the
> > > importance of a strong MAC and a strong block chaining mode as well as
> > > a strong cipher.
> >
> > Would you care to help with the wording/reqs ?
>
> I was kind of hoping to get away with handwaving there.  8-)
>
> But sure, I'm willing to try to work on this, though it's not
> immediately obvious what final text to propose.

It would be good if someone with stronger crypto skills than I had a
look at the following:

   2.1.1   Support Secure Management Channels . . . . . . . . . . . .  8
   2.2     In-Band Management Requirements  . . . . . . . . . . . . . 11
   2.2.1   Use Non-Proprietary Encryption . . . . . . . . . . . . . . 12
   2.2.2   Use Strong Encryption  . . . . . . . . . . . . . . . . . . 12
   2.2.3   Key Management Must Be Scalable  . . . . . . . . . . . . . 13
   2.12.12 Support Device-to-Device Authentication .. . . . . . . . . 43

> Is ANSI.T1.276-200x publicly available at no charge?  A google search
> for ANSI.T1.276-200x found me your draft on port111.com, and nothing
> else.

Chris posted the latest references.    Do people think references
should removed if it's not freely available/citable ?

>
> In looking at the text again just now, I'm not really convinced that
> my original criticism of the text was entirely valid: when one talks
> about encryption algorithms, as the draft does, the first definition
> that comes to my mind are symmetric ciphers like 3DES, AES, RC4, etc.
> But the algorithm used to do initial key exchange is also in some
> sense a cryptographic algorithm, for example, and if you define
> ``encryption algorithm'' sufficiently broadly, the text might well be
> correct.  (It probably still could be made less ambiguous, though.)

Have at it.

>
> The focus should not be on key lengths, though.  The easiest way to
> defeat cryptography (assuming there aren't known buffer overflows,
> which is even easier when it happens to work) tends to be by attacking
> the initial part of the session, when the client and server
> authenticate themselves to each other.  For example, when using the
> current Kerberos v5 protocol with passwords, an attacker probably
> effectively basically needs to be able to crack a 30 bit key.  Even if
> you're using 256 bit AES to encrypt the later parts of the session.
> With the sshv2 protocol, if password auth is being used, all you need
> to do is cons up a new host public key and offer it to the user and
> hope they accept it, at which point they will send you the password
> effectively in the clear.  These attacks turn out to be even easier
> than cracking 56 bit DES, in most cases.

The requirement is not a particular key length.  The requirement
is "strong" encryption...as a method to ensure privacy and integrity
of management communications.   The problem with specifying particular
key lengths is that the relative strength of a particular size key
degrades over time....so it looks something like this:

  Requirement: strong cryptography (general, does not change)

  Justification: ensure privacy, integrity

  Implemenation: [give examples of current "strong" crypto]

  Warning: Warn about degradation of key lengths over time.

> Maybe we want language saying that devices need to support
> well-understood cryptographic protocols such as sshv2, TLS, and/or
> IPsec, and let the documents of those working groups speak to the
> strength of the encryption algorithms.

Could be.   Certianly those could be mentioned in the implementation
sections of 2.1.1 ("secure managemnt chanels") or 2.3 ("OoB
Management").

> I wonder if it would be useful to define two levels of management
> access: access for a handful of people who maintain the authentication
> infrastructure, and some of the core functionality of the network
> devices, and then a second class of access for people who only need
> access when things are mostly working.
>
> For example, if an NSP has a router with 100 customer circuits on it,
> and a couple of circuits going to other routers the NSP has, the
> technicians who troubleshoot customer circuits can reasonably use
> Kerberos, or can use some sort of X.509 based system that does online
> verification that there's no revocation certificate out there.  The
> people responsible for keeping that router connected to the NSP's
> backbone are probably going to need to know some kind of password that
> they can use to log in on the console port.

See if these do it for you.

   2.12.13 Ability to Define Privilege Levels        . . . . . . . . . . . . 44
   2.12.14 Ability to Assign Privilege Levels to Users        . . . . . . . 44
   2.12.15 Default Privilege Level Must Be Read Only        . . . . . . . . 45

One of the bits of feedback I got at RIPE was that there needs to be
more work on authorization....details are supposedly forthcoming.

> One other interesting question is whether you could build a protocol
> for automatic updates of that password.

New protocols and database problems are outside the scope.

> (Note that this may be a case
> where you really do want to share a password between lots of people,
> so that if the update breaks, you will actually notice; if you have an
> account per user, and a disgruntled employee leaves and the protocol
> only deletes his account on half the routers, is anyone ever really
> going to notice?  My experience has been that anything that depends on
> people checking logs and noticing that something is wrong will go
> unnoticed sooner or later.)

One can imagine a system whereby centalized AAA accounts are used to
grant read access to a copy of the enable/line passwords for devices
which the user is authorized, and automated procedures (scripts) are
used to update the enable/line passwords...but again, outside the
scope.

>
> > > Does ``2.3.4 No Forwarding Between Management and Data Planes''
> > > prohibit a command on the console port from initiating an outbound
> > > telnet session to the data forwarding interface?
> >
> > The intent here is primarily to make it impossible for management
> > to be attempted from the public/data forwarding side.   If you
> > can't get the packets there, you can't attempt management.
>
> OK.  I think being more explicit about that in the draft would be
> useful.

Will do.   This is moving to the info (non BCP) side.

> OK.  So the idea then is that the management network is a
> well-isolated network, and that there won't be attackers on the
> management network.

Yes.

> Does that actually work in the real world?  Can people be trusted to
> not accidentally plug the management network into the real network?

So that's an implementation detail left as an exercize for the reader.
The point in having them in the draft was to enumerate the features
that make it possible.

> > > ``2.5.5 Support Automatic Anti-spoofing for Single-Homed Networks''
> > > should clearly state whether/how it applies to NAT.

> >
> > Suggestions ?
>
> Maybe it should say that if you're doing NAT, that you MUST default to
> blocking all packets that don't have a source address that gets
> translated by the NAT.
>
> Of course, that default for the NAT case is a more strict requirement
> than what is recommended in the non-NAT case, but I don't think that
> necessarily makes it incorrect.  On the other hand, I'm thinking of
> consumer-grade devices here,

I think NAT is not a requirement in large network infrastructure
(anybody using NAT between the core and edge ?)

>
> > > The wording of ``2.7.7 Ability to Filter Without Performance
> > > Degradation'' seems to imply that if you have a SOHO NAT box that does
> > > forwarding and filtering on a microprocessor needs to delibrately
> > > waste cycles when it's not filtering if it can't keep up with a full
> > > 10mb worth of traffic when not filtering.
> >
> > ???
>
> Sorry, I meant to say that that section seems to imply that if you
> have a SOHO NAT box that does forwarding and filtering on a
> microprocessor, it needs to delibrately waste cycles when it's not
> filtering if it can't keep up with a full 10mb worth of traffic when
> filtering.

That would be backwards.   It's simply saying if you can pass N/pps
w/o filtering, you should be able to passs N/pps with filtering.


> > >  I think the more
> > > interesting thing to focus on may be that if forwarding is done by an
> > > ASIC, that ASIC needs to support filtering.  (I think the Cisco 2500
> > > and 2600 series routers are examples of routers that lose a *lot* of
> > > performance in certain filtering cases, because they switch from ASIC
> > > to microprocessor based filtering, but I may be a bit confused about
> > > that, and I haven't been paying much attention to Cisco's product line
> > > in the last couple years.)
> >
> > ASICs are implmenation.   The requirement is fast filtering.
> > It has moved to the info doc, but I could be convinced, based
> > on Dave Newman's article/evaluations, to move it back to BCP.
>
> Yes.  You saying that makes me wonder if requiring that the same
> implementation be used both with and without the filtering is the
> right requirement.

We're not requiring implementations, we're requiring capabilities
and giving examples of implemnations.

>
> > > The justification under ``2.9.1 Ability to Accurately Count Filter
> > > Hits'' seems bogus.  Things that automatically retry will be seen as a
> > > greater threat, if you go by packet count, even if the following
> > > packets don't differ in any interesting way.  Some of the subtle
> > > things that nmap can try to do make it very hard to get reliable
> > > information out of this.
> >
> > The requirement is accurate counting of the matching traffic presented.
> > The requirment is not AI that does attack analysis.   We still need
> > humans for that.
>
> I think the warnings should say that.

OK.  Will add.

[... to be continued ...]

Thanks,
--George Jones