Nokia IP265 Security Guide - Page 15

SmartDashBoard Check Point Management Station - during - how to use console login

Page 15 highlights

• CLI (local) - the Crypto Officer must authenticate by using user ID and password. The password must be at least six characters long. Numeric, alphabetic (upper and lowercase), and keyboard and extended characters can be used. • CLI (remote) - the Crypto Officer must first successfully authenticate during the SSH session establishment. Before starting the SSH session, the Crypto Officer must login locally at initialization through the console CLI and enter an authorized RSA or DSA public key generated at the client. This public key will be used to authenticate the Crypto Officer during SSH session establishment. Once a session is established, the Crypto Officer can also be asked to authenticate again by using the user ID and password before the management interface can finally be accessed. • SNMP - (IPSO 3.9 only): the Crypto Officer must authenticate by using the user ID and password. It is the same password used to access the CLI. The only restriction is that the password must be at least eight characters long. • SmartDashBoard (Check Point Management Station) - during the TLS session establishment between the Check Point management station and the gateway, the Crypto Officer must authenticate by using a digital certificate issued by a trusted Certification Authority (CA). 2.4.3.2 User Authentication User authentication to the module is performed during IKE using digital certificates or pre-shared keys. The pre-shared keys must be at least six characters long and use at least four different characters. 2.4.3.3 Estimated Strength of the Authentication Mechanisms The estimated strength of each authentication mechanism implemented by the module is described in Table 5. Authentication Type Strength DSA-based authentication (SSHv2) DSA signing and verification is used to authenticate the module during SSHv2. This mechanism is as strong as the DSA algorithm using a 1024 bit key pair. RSA-based authentication (SSHv1, SSHv2 and TLS handshake) RSA encryption and decryption is used to authenticate the module during SSHv1, SSHv2, and the TLS handshake. This mechanism is as strong as the RSA algorithm using a 1024 bit key pair. © Copyright 2005, 2006, 2007 Nokia Page 15 of 43 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43

CLI (local) – the Crypto Officer must authenticate by using user ID
and password. The password must be at least six characters long.
Numeric, alphabetic (upper and lowercase), and keyboard and
extended characters can be used.
CLI (remote) – the Crypto Officer must first successfully
authenticate during the SSH session establishment. Before starting
the SSH session, the Crypto Officer must login locally at
initialization through the console CLI and enter an authorized RSA
or DSA public key generated at the client. This public key will be
used to authenticate the Crypto Officer during SSH session
establishment. Once a session is established, the Crypto Officer
can also be asked to authenticate again by using the user ID and
password before the management interface can finally be
accessed.
SNMP – (
IPSO 3.9 only
): the Crypto Officer must authenticate by
using the user ID and password. It is the same password used to
access the CLI. The only restriction is that the password must be at
least eight characters long.
SmartDashBoard (Check Point Management Station) – during the
TLS session establishment between the Check Point management
station and the gateway, the Crypto Officer must authenticate by
using a digital certificate issued by a trusted Certification Authority
(CA).
2.4.3.2
User Authentication
User authentication to the module is performed during IKE using digital
certificates or pre-shared keys. The pre-shared keys must be at least six
characters long and use at least four different characters.
2.4.3.3
Estimated Strength of the Authentication Mechanisms
The estimated strength of each authentication mechanism implemented
by the module is described in Table
5
.
Authentication
Type
Strength
DSA-based
authentication
(SSHv2)
DSA signing and verification is used to authenticate the
module during SSHv2. This mechanism is as strong as the
DSA algorithm using a 1024 bit key pair.
RSA-based
authentication (SSHv1,
SSHv2 and TLS
handshake)
RSA encryption and decryption is used to authenticate the
module during SSHv1, SSHv2, and the TLS handshake. This
mechanism is as strong as the RSA algorithm using a 1024
bit key pair.
© Copyright 2005, 2006, 2007
Nokia
Page 15 of 43
This document may be freely reproduced and distributed whole and intact including this Copyright Notice.