RFC 3871 Operational Security Requirements September 2004
Note that for *new protocols* [RFC3631] says the following:
"Simple keyed hashes based on MD5 [RFC1321], such as that used in
the BGP session security mechanism [RFC2385], are especially to be
avoided in new protocols, given the hints of weakness in MD5."
While use of such hashes in deployed products and protocols is
preferable to a complete lack of integrity and authentication
checks, this document concurs with the recommendation that new
products and protocols strongly consider alternatives.
Warnings.
This list is not exhaustive. Other strong, well reviewed
algorithms may meet the requirement. The dynamic nature of the
field means that what is good enough today may not be in the
future.
Strength is relative. Long keys and strong algorithms are
intended to increase the work factor required to compromise the
security of the data protected. Over time, as processing power
increases, the security provided by a given algorithm and key
length will degrade. The definition of "Strong" must be
constantly reevaluated.
There may be legal issues governing the use of cryptography and
the strength of cryptography used.
This document explicitly does not attempt to make any
authoritative statement about what key lengths constitute "strong"
cryptography. See [RFC3562] and [RFC3766] for help in
determining appropriate key lengths. Also see [Schneier] chapter
7 for a discussion of key lengths.
2.2.3. Use Protocols Subject To Open Review For Management
Requirement.
If cryptography is used to provide secure management channels,
then its use MUST be supported in protocols that are subject to
"open review" as defined in Section 1.8. These SHOULD be used by
default. The device MAY optionally support the use of
cryptography in protocols that are not open to review.
Jones Informational [Page 14]
Unlimited Web Hosting
|
|
TotalRoute.net Business web hosting division of Vision Web Hosting Inc. All rights reserved. |