[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to review comments from Pekka Savola (1 of ?)
Date and Time: 2004-02-04, 21:54:7
Version: 03
Commented by: Kessens, David
State before Comment: IESG Evaluation - Defer
State after Comment: IESG Evaluation - Defer
Comment:
Received the following long list of comments from
Pekka on ops directorate (previous list was truncated):
ps> substantial
ps> -----------
ps>
ps> 2.1.1 Support Secure Channels For Management
ps>
ps> [...]
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.
ps>
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.)
ps>
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.
Better ?
04> This section lists security requirements that support secure in-band
04> management.
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>
ps>
ps> (or in some other way take better into an account that no same ISP
ps> will
ps> *ever* just choose _only_ in-band management.)
ps>
ps> o in-band management traffic on public interfaces may be
ps> intercepted
ps>
ps> ==> also:
ps>
ps> o in-band management traffic on public interfaces may be
ps> intercepted,
ps> but typically that would require a significant compromise in the
ps> routing system.
04> however this would typically require a significant compromise in the
04> routing system.
ps> ..
ps>
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.
ps>
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.
ps> [[ I have skipped the review of the rest of the 2.2.X sections as
ps> they seem to be highly problematic, and should probably be fixed
ps> with the help of the security area guys ]]
I would, of course, welcome feedbak from those with more depth in crypto.
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.
> 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.
to be continued...
Thanks,
---George