User guide

Aruba Networks Security Target
Page 39 of 67
#469, #466. SHS #2250, #2249, #2246. RNG #1250. DRBG #433.
HMAC #1666, #1663. KBKDF #16. Component Validation #251,
#232, #152, #150. The CAVP list for each algorithm can be found at
http://csrc.nist.gov/groups/STM/cavp/validation.html.
6.2.1 Standards Conformance – Key Generation / Establishment
6.2.1.1 RSA
72 The TOE utilizes RSA for key establishment within HTTPS/TLS and IPSec. The
TOE’s implementation of RSA conforms to NIST Special Publication 800-56B,
“Recommendation for Pair-Wise Key Establishment Schemes Using Integer
Factorization Cryptography”.
73 Sections 5 through 9 of NIST Special Publication 800-56B are applicable to the TOE.
The TOE conforms to all shall, shall-not, should and should-not statements. There
are no TOE-specific implementation extensions.
6.2.1.2 Diffie-Hellman
74 The TOE utilizes Diffie-Hellman within IPSec and SSH. The TOE’s implementation of
Diffie-Hellman conforms to NIST Special Publication 800-56A, “Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography”.
75 Diffie-Hellman relevant subsections of sections 5 through 8 of NIST Special
Publication 800-56A are applicable to the TOE. The TOE conforms to all shall, shall-
not, should and should-not statements. There are no TOE-specific implementation
extensions.
6.2.1.3 ECDSA
76 The TOE utilizes ECDSA within IPSec. The TOE’s implementation of ECDSA
conforms to NIST Special Publication 800-56A, “Recommendation for Pair-Wise Key
Establishment Schemes Using Discrete Logarithm Cryptography”.
77 Elliptic Curve Cryptography (ECC) relevant subsections of sections 5 through 8 of
NIST Special Publication 800-56A are applicable to the TOE. The TOE conforms to
all shall, shall-not, should and should-not statements. There are no TOE-specific
implementation extensions.
6.2.2 Critical Security Parameters
78 Table 13 below identifies all secret and private keys and Critical Security Parameters
(CSPs), the related zeroization procedures and whether any interface is available to
view the plaintext key.
79 Note that the plaintext keys identified in Table 13 are not able to be viewed via a
‘normal user interface’, that is, no user interface is provided by design and therefore
the keys are protected. Per the NDPP FPT_SKP_EXT.1 application note, it is
understood that the administrator could directly read memory to view these keys,
[however to] do so is not a trivial task and may require substantial work on the part of
an administrator. Since the administrator is considered a trusted agent, it is assumed
they would not endeavor in such an activity. Shared secrets entered by a user are
only viewable during entry.
80
Table 13: CSPs