HP A-Series Especificações descarregar pdf (Página 47)

Security Target Version 1.02, 08/16/2013

being received, the TOE uses a buffer to build all packet information. Once complete, the packet is checked to

ensure it can be appropriately decrypted. However, if it is not complete when the buffer becomes full (256K bytes)

the packet will be dropped.

The TOE includes an implementation of IPsec in accordance with RFC 4303 for security. The primary

cryptographic algorithms used by the TOE include AES-CBC-128 and AES-CBC-256 (both specified by RFC 3602

along with IKEv1 as defined in RFCs 2407, 2408, 2409, and RFC 4109. The TOE supports both main and

aggressive modes, though aggressive mode is disabled in FIPS mode as indicated above. Furthermore,

"confidentiality only" ESP mode is disabled by default.

IKEv1 SA lifetime and volume limits can be configured via a CLI function by an authorized administrator and can

be limited to 24 hours (actually any value between 60 and 604,800 seconds) for phase 1 and 8 hours (actually any

value from 180 to 604,800 seconds) for phase 2 and also to as little as 2.5 MB (actually any value between 2,560

and 4,294,967,295 KB) of traffic for phase 2. The IKEv1 protocols implements by the TOE include DH Groups 2

(1024-bit MODP), 5 (1536-bit MODP), and 14 (2048-bit MODP) and utilize RSA (aka rDSA) peer authentication.

In the IKEv1 phase 1 and phase 2 exchanges, the TOE and peer will agree on the best DH group both can support.

When the TOE initiates IKE negotiation, the DH group is sent in order according to the peer’s configuration. When

the TOE receives an IKE proposal, it will select the first match and the negotiation will fail if there is no match.

During IKEv1 phase 1 authentication is based on a verifiable signature as described in RFC2409.

The TOE can be configured to use pre-shared keys with a given peer. When a pre-shared key is configured, the

IPsec tunnel will be established using the configured pre-shared key provided the peer also has the pre-shared key.

Pre-shared keys used for IPsec can be constructed of essentially any alphabetic character (upper and lower case),

numerals, and special characters (e.g., “!”, “@”, “#”, “$”, “%”, “^”, “&”, “*”, “(“, and “)”) and can be anywhere

from 1 to 128 characters in length (e.g., 22 characters). The TOE requires suitable keys to be entered by an

authorized administrator using a CLI function.

The following sections summarize how keys are established and used for IPsec and SSH. Each feature using a key

pair must generate its own new key pair.

If the key pair is used for IPsec, the operational procedure to establish and use the key pair is as follows:

1. The administrator configures the device with standard IPsec configuration and must specify the “rsa-signature”

authentication method for the IKE proposal.

2. The administrator generates the RSA key pair via the command line “public-key local create rsa”. This key pair

is used for IKE negotiation.

3. The administrator configures the PKI entity and PKI domain to retrieve and request the CA certificate and local

certificate with RSA key pairs. The local certificate has public RSA key.

4. IKE negotiation will be triggered to set up SAs when there is protected subnet traffic in the device.

5. In the IKE phase 1 main mode negotiation, the 5th IKE packet has signature payload signed by RSA private

key and certificate payload with RSA public key. When receiving this IKE packet, the device verifies the

signature payload using the public key in the certificate payload.

If the key pair used for SSH, and the device is an SSH server, the operational procedure to establish and use the key

pair is as follows:

1. The administrator generates the RSA key pair via the command line “public-key local create rsa”. This

command will replace the key pair for the IPsec and generate a new one for SSH.

2. The administrator configures the other SSH server configuration and the device as SSH server.

3. When an SSH client accesses the device, during the key exchange stage, the rsa public key of the device is sent

to the client.

4. RSA key pairs are required for generating the session key and session ID in the key exchange stage, and can

also be used by a client to authenticate the server. When a client tries to communicate with a server, it

compares the public key it receives from the server with the server public key it saved locally. If the keys are

consistent, the client uses the public key to authenticate the digital signature it receives from the server. If the

digital signatures are consistent, the authentication succeeds.

The Cryptographic support function is designed to satisfy the following security functional requirements:

1 2 ... 42 43 44 45 46 47 48 49 50 51 52 ... 65 66

Comentários a estes Manuais

Sem comentários

HP A-Series Especificações Página 47

Comentários a estes Manuais

Manuais e produtos relacionados com Barebones PC/estação de trabalho HP A-Series