[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reply to review comments from Pekka Savola (1 of ?)
On Tue, 24 Feb 2004, George Jones wrote:
> ps> Protocols that use encryption: SSH, SFTP, SNMPv3, BGP, NTP,
> ps> Kerberos.
> ps>
> ps>
> ps> ==> This needs some additional warnings, as the MUST requirements
> ps> cannot
> ps> be fulfilled at present without resorting to IPsec. How do you
> ps> perform
> ps> Secure Logging for example otherwise?
>
> This is one that's going to take more thought. You are right about
> logging. Will come back to this one.
Ok.
> ps> ==> s/use/are able to use/ --- let's not give a false sense of
> ps> security
> ps> that they would automatically yield security. Also,
> ps> NTP or BGP do not provide encryption, but rather authentication
> ps> and integrity.
>
> Right. That was already pointed out. List of protocols is completly
> gone now, replaced by a citation of the IABs fine new securty
> mechanisms info rfc:
>
> 04> Examples.
> 04>
> 04> See [RFC3631] for a current list of mechanisms that can be used
> 04> to support secure management.
> 04>
> 04> Later sections list requirements for supporting in-band
> 04> management (Section 2.2) and out-of-band management (Section
> 04> 2.3) as well as trade-offs that must be weighed in considering
> 04> which is appropriate to a given situation.
>
> I could leave it at that (easiest, citing well thought out and well
> reviewed general advice) or revert to a table showing protocols
> grouped by class (logging, time, routing) vs requirement
> (confidentiality, integrity, etc.)
The problem with the above statement is that RFC3631 lists "security
primitives" (in a way) which different protocols-to-be-secured could
use to achieve the security properties. This might lead to a
disconnect which you're probably referring to. How do we get from the
list of "ways to add security in a system in general" to "secure
protocols" ?
> ps> 2.2 In-Band Management Requirements
> ps>
> ps> This section lists security requirements for devices that are
> ps> managed
> ps> In-band.
> ps>
> ps> ==> "are managed", "will be managed" or "can be managed"? Can the
> ps> user
> ps> know before purchasing a box how it's going to be managed if not
> ps> the last one?
>
> Hopefully someone knows how the're going to manage a device before
> they purchase it.
Not necessarily, and that might change during the lifetime of the
device.
> Better ?
>
> 04> This section lists security requirements that support secure in-band
> 04> management.
Yep.
> ps>
> ps> o saturation of customer lines or interfaces can make the device
> ps> unmanageable
> ps>
> ps> ==> this is not balanced, reword e.g. to:
>
> It wasn't intended to be balanced. It was intended to list the
> problems of in-band management, not solutions or alternatives.
> Those come elsewhere.
>
> ps>
> ps> o saturation of customer lines or interfaces can make the device
> ps> unmanageable, unless an out-of-band management has been reserved
> ps> specifically to avoid this problem.
>
> Better ?
>
> 04> unless out-of-band management resources have reserved.</t>
Yep. ("have been reserved" ?)
> ps> o Since the same networking code and interfaces are shared for
> ps> management and customer data, it is not possible to isolate
> ps> management functions from failures in other areas. (For example,
> ps> a
> ps> "magic packet" or buffer overrun that causes the data forwarding
> ps> portions of a router to crash will also likely make it
> ps> impossible
> ps> to manage. This would not necessarily be the case if the
> ps> management and data forwarding elements were completely
> ps> separated)
> ps>
> ps>
> ps>
> ps> ==> this seems so misguided that I would remove it completely or
> ps> reword
> ps> it a LOT. If you crash a forwarding element with a magic packet, it
> ps> will be unmanageable using out-of-band mechanisms as well.
>
> Try this:
>
> 04> o Public interfaces used for in-band management may become
> 04> unavailable due to bugs (e.g. buffer overflows being exploited)
> 04> while out-of-band interfaces (such as a serial console device)
> 04> remain available.
better.
> ps> 2.2.1 Use Encryption Algorithms Subject To Open Review
> ps>
> ps> ==> the author has probably mixed the terms "Encryption" and
> ps> "Cryptography", as continuously he keeps referring to mechanisms which
> ps> use e.g. signatures but provide no encryption. A lot of sections need
> ps> to be re-reviewed.
>
> Lacking pointers to specific problems, I've done what I can to fix it.
> I most cases this ment s/encryption/cryptography/
>
> See interim results @
> http://www.port111.com/opsec/draft-jones-opsec-04.txt
> rather than pasting large bits in here.
OK -- I read this through, only quickly, and it seemed
reasonable. The for the rest of 2.2.X as well.
> ps>
> ps> Requirement. If encryption is used to provide secure management
> ps> channels, then it MUST support encryption algorithms that are
> ps> subject to "open review" as defined in Section 1.8.
> ps>
> ps> ==> This is ambiguous. It could be read to say, "all encryption
> ps> algorithms subject to open review MUST be supported" while it probably
> ps> tries to say something slightly different.
>
> 04> 2.2.1 Use Cryptographic Algorithms Subject To Open Review
> 04>
> 04> Requirement. If cryptography is used to provide secure management
> 04> functions, then there MUST be an option to use algorithms that
> 04> are subject to "open review" as defined in Section 1.8 to
> 04> provide these functions. These SHOULD be used by default. The
> 04> device MAY optionally support algorithms that are not open to
> 04> review.
Ok.
> > And if not all, what's
> ps> the "mandatory to implement" set of mechanisms so that
> ps> interoperability
> ps> will be ensured?
>
> This is trying to say that open review is necessary for security, not
> that it is suficient for interoperability.
Ok.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings