[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