HP A 5120 Manual

							 
181 
To do… Use the command… Remarks 
Enter system view system-view — 
Display the local RSA host public 
key on the screen in a specified 
format, or export it to a specified 
file 
public-key local export rsa { 
openssh | ssh1 | ssh2 } [ 
filename ] Select a command according to 
the type of the key to be 
exported. Display the local DSA host public 
key on the screen in a specified 
format or export it to a specified 
file 
public-key local export dsa { 
openssh | ssh2 } [ filename ] 
 
Destroying an asymmetric key pair 
You  may  need  to  destroy  an  asymmetric  key  pair  and  generate  a  new  pair  when  an  intrusion  event  has 
occurred, the storage media of the device is replaced, the asymmetric key has been used for a long time, 
or the certificate from the Certificate Authority (CA) expires. To check the certificate status, use the display 
pki  certificate command.  For  more  information  about  the  CA  and  certificate,  see  the chapter ―PKI 
configuration.‖ 
Follow these steps to destroy an asymmetric key pair: 
To do… Use the command… Remarks 
Enter system view system-view — 
Destroy an asymmetric key pair public-key local destroy { dsa | 
rsa } Required 
 
Configuring a peer public key 
To enable  your  local  host  to authenticate a peer,  configure the peer RSA  or  DSA  public key  on  the  local 
host. The following methods are available: 
 Import  it  from a public  key  file—Obtain  a  copy  of the peer public  key  file through  FTP  or  TFTP  (in 
binary  mode)  first,  and  then  import  the  public  key  from  the  file.  During  the  import  process,  the 
system  automatically  converts  the  public  key  to  a  string in the Public  Key  Cryptography  Standards 
(PKCS) format. HP recommends that you follow this method to configure the peer public key. 
 Configure  it  manually—If  the peer is  an  HP  device,  you  can  use  the display  public-key  local public 
command to  view and  record  its public  key. On  the  local  host,  input  or  copy the  key  data  in public 
key  code  view. A public  key  displayed by other  methods  may  not in  the PKCS format,  and  the 
system cannot save the format-incompliant key.  
 NOTE: 
The device supports up to 20 peer pubic keys.  
Follow these steps to import a peer host public key from the public key file: 
To do… Use the command… Remarks 
Enter system view system-view —  
						

							 
182 
To do… Use the command… Remarks 
Import the peer host public key 
from the public key file 
public-key peer keyname import 
sshkey filename Required 
 
Follow these steps to configure a peer public key manually: 
To do… Use the command… Remarks 
Enter system view system-view — 
Specify a name for a peer public 
key and enter public key view  public-key peer keyname Required 
Enter public key code view public-key-code begin — 
Configure the peer host or server 
public key Type or copy the key 
Required 
Spaces and carriage returns are 
allowed between characters. 
Return to public key view public-key-code end 
Required 
When you exit public key code 
view, the system automatically 
saves the public key. 
Return to system view peer-public-key end — 
 
 NOTE: 
Do not configure an RSA server public key of the peer for identity authentication in SSH applications. 
Authentication in SSH applications uses the RSA host public key. For more information about SSH, see 
the chapter “SSH2.0 configuration.”  
Displaying and maintaining public keys 
To do… Use the command… Remarks 
Display the public keys of the 
local key pairs 
display public-key local { dsa | 
rsa } public [ | { begin | exclude 
| include } regular-expression ]  
Available in any view 
Display the peer public keys 
display public-key peer [ brief | 
name publickey-name ] [ | { begin 
| exclude | include } regular-
expression ]  
 
Public key configuration examples 
Configuring a peer public key manually 
Network requirements 
As shown in Figure  52,  to prevent  illegal  access, Device B authenticates  Device  A  through  a digital 
signature. Before configuring authentication parameters on Device B, configure the public key of Device A 
on Device B.  
						

							 
183 
 Configure  Device  B  to  use  the asymmetric key  algorithm  of RSA for  identity  authentication  of  Device 
A. 
 Manually configure the host public key of Device A on Device B. 
Figure 52 Network diagram for manually configuring a peer public key 
 
 
Configuration procedure 
1. Configure Device A. 
# Create RSA key pairs on Device A. 
 system-view 
[DeviceA] public-key local create rsa 
The range of public key size is (512 ~ 2048). 
NOTES: If the key modulus is greater than 512, 
It will take a few minutes. 
Press CTRL+C to abort. 
Input the bits of the modulus[default = 1024]: 
Generating Keys... 
++++++ 
++++++ 
++++++++ 
++++++++ 
# Display the public keys of the created RSA key pairs. 
[DeviceA] display public-key local rsa public 
 
===================================================== 
Time of Key pair created: 09:50:06  2011/01/07 
Key name: HOST_KEY 
Key type: RSA Encryption Key 
===================================================== 
Key code: 
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814F9854
C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669A784A
D597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3BCA80A
AB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001 
 
===================================================== 
Time of Key pair created: 09:50:07  2011/01/07 
Key name: SERVER_KEY 
Key type: RSA Encryption Key 
===================================================== 
Key code: 
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87BB6158E3
5000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3CFA9E84B
9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0203010001  Device ADevice B   
						

							 
184 
2. Configure Device B. 
#  Configure  the  host  public  key  of  Device  A  on  Device  B.  In public key  code  view,  input the host  public 
key of Device A. The host public key is the content of HOST_KEY displayed on Device A using the display 
public-key local dsa public command. 
 system-view 
[DeviceB] public-key peer devicea 
Public key view: return to System View with peer-public-key end. 
[DeviceB-pkey-public-key] public-key-code begin 
Public key code view: return to last view with public-key-code end. 
[DeviceB-pkey-key-
code]30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814
F9854C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669
A784AD597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3B
CA80AAB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001 
[DeviceB-pkey-key-code] public-key-code end 
[DeviceB-pkey-public-key] peer-public-key end 
# Display the host public key of Device A saved on Device B. 
[DeviceB] display public-key peer name devicea 
 
===================================== 
  Key Name  : devicea 
  Key Type  : RSA 
  Key Module: 1024 
===================================== 
Key Code: 
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814F9854
C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669A784A
D597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3BCA80A
AB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001 
Importing a peer public key from a public key file 
Network requirements 
As shown in Figure  53,  to prevent  illegal  access, Device B authenticates  Device  A  through  a  digital 
signature. Before configuring authentication parameters on Device B, configure the public key of Device A 
on Device B. 
 Configure  Device  B  to  use  the asymmetric key  algorithm  of RSA for  identity  authentication  of  Device 
A. 
 Import the host public key of Device A from the public key file to Device B. 
Figure 53 Network diagram for importing a peer public key from a public key file 
 
 
Configuration procedure 
1. Create key pairs on Device A and export the host public key.  Device ADevice B
10.1.1.1/2410.1.1.2/24   
						

							 
185 
# Create RSA key pairs on Device A. 
 system-view 
[DeviceA] public-key local create rsa 
The range of public key size is (512 ~ 2048). 
NOTES: If the key modulus is greater than 512, 
It will take a few minutes. 
Press CTRL+C to abort. 
Input the bits of the modulus[default = 1024]: 
Generating Keys... 
++++++ 
++++++ 
++++++++ 
++++++++ 
# Display the public keys of the created RSA key pairs. 
[DeviceA] display public-key local rsa public 
 
===================================================== 
Time of Key pair created: 09:50:06  2011/01/07 
Key name: HOST_KEY 
Key type: RSA Encryption Key 
===================================================== 
Key code: 
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814F9854
C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669A784A
D597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3BCA80A
AB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001 
 
===================================================== 
Time of Key pair created: 09:50:07  2011/01/07 
Key name: SERVER_KEY 
Key type: RSA Encryption Key 
===================================================== 
Key code: 
307C300D06092A864886F70D0101010500036B003068026100999089E7AEE9802002D9EB2D0433B87BB6158E3
5000AFB3FF310E42F109829D65BF70F7712507BE1A3E0BC5C2C03FAAF00DFDDC63D004B4490DACBA3CFA9E84B
9151BDC7EECE1C8770D961557D192DE2B36CAF9974B7B293363BB372771C2C1F0203010001 
# Export the RSA host public key to a file named devicea.pub. 
[DeviceA] public-key local export rsa ssh2 devicea.pub 
[DeviceA] quit 
2. Enable the FTP server function on Device B. 
# Enable the FTP server function, create an FTP user with the username ftp, password 123, and user level 
3. 
 system-view 
[DeviceB] ftp server enable 
[DeviceB] local-user ftp 
[DeviceB-luser-ftp] password simple 123 
[DeviceB-luser-ftp] service-type ftp  
						

							 
186 
[DeviceB-luser-ftp] authorization-attribute level 3 
[DeviceB-luser-ftp] quit 
3. Upload the public key file of Device A to Device B. 
# FTP the public key file devicea.pub to Device B with the file transfer mode of binary. 
 ftp 10.1.1.2 
Trying 10.1.1.2 ... 
Press CTRL+K to abort 
Connected to 10.1.1.2. 
220 FTP service ready. 
User(10.1.1.2:(none)):ftp 
331 Password required for ftp. 
Password: 
230 User logged in. 
[ftp] binary 
200 Type set to I. 
[ftp] put devicea.pub 
227 Entering Passive Mode (10,1,1,2,5,148). 
125 BINARY mode data connection already open, transfer starting for /devicea.pub. 
226 Transfer complete. 
FTP: 299 byte(s) sent in 0.189 second(s), 1.00Kbyte(s)/sec. 
4. Import the host public key of Device A to Device B. 
# Import the host public key of Device A from the key file devicea.pub to Device B. 
[DeviceB] public-key peer devicea import sshkey devicea.pub 
# Display the host public key of Device A saved on Device B. 
[DeviceB] display public-key peer name devicea 
 
===================================== 
  Key Name  : devicea 
  Key Type  : RSA 
  Key Module: 1024 
===================================== 
Key Code: 
30819F300D06092A864886F70D010101050003818D0030818902818100D90003FA95F5A44A2A2CD3F814F9854
C4421B57CAC64CFFE4782A87B0360B600497D87162D1F398E6E5E51E5E353B3A9AB16C9E766BD995C669A784A
D597D0FB3AA9F7202C507072B19C3C50A0D7AD3994E14ABC62DB125035EA326470034DC078B2BAA3BC3BCA80A
AB5EE01986BD1EF64B42F17CCAE4A77F1EF999B2BF9C4A10203010001  
						

							 
187 
PKI configuration 
PKI overview 
The Public Key Infrastructure  (PKI)  is a  general  security  infrastructure used  to provide information  security 
through public key technologies.  
PKI,  also  called  asymmetric  key  infrastructure,  uses  a  key  pair  to  encrypt  and  decrypt  the  data. The  key 
pair  consists of  a  private  key  and  a  public  key.  The  private  key  must  be  kept  secret but the  public  key 
needs to be distributed. Data encrypted by one of the two keys can only be decrypted by the other. 
A  key  problem with PKI is  how  to  manage  the  public  keys. PKI  employs the digital  certificate mechanism 
to  solve  this  problem. The digital  certificate mechanism  binds  public  keys  to  their  owners,  helping 
distribute public keys in large networks securely.  
With  digital certificates,  the  PKI  system  provides  network  communication  and  e-commerce  with  security 
services such as user authentication, data non-repudiation, data confidentiality, and data integrity. 
HPs PKI system provides certificate management for Secure Sockets Layer (SSL). 
PKI terms 
 Digital certificate 
A  digital certificate  is  a  file  signed by a  certificate  authority  (CA) for  an  entity.  It  includes  mainly  the 
identity  information  of  the  entity,  the  public  key  of  the  entity,  the  name  and  signature  of  the  CA,  and  the 
validity  period  of  the  certificate.  The  signature of  the  CA  ensures  the  validity  and  authority  of  the 
certificate. A  digital  certificate  must  comply  with  the  international  standard  of  ITU-T X.509. The  most 
common standard is X.509 v3. 
This document discusses two types of certificates: local certificate and CA certificate. A local certificate is 
a  digital  certificate  signed  by  a  CA  for an  entity. A CA  certificate is  the certificate  of  a CA. If  multiple 
CAs are trusted by different users in a PKI system, the CAs will form a CA tree with the root CA at the top 
level. The  root  CA  has  a  CA  certificate  signed  by  itself, and each  lower  level  CA  has  a  CA  certificate 
signed by the CA at the next higher level. 
 CRL 
An  existing  certificate might need  to  be  revoked  when,  for  example,  the  username  changes,  the  private 
key leaks, or the user stops the business. Revoking a certificate removes the binding of the public key with 
the  user  identity  information.  In  PKI,  the  revocation  is  made  through  certificate  revocation  lists  (CRLs). 
Whenever  a  certificate  is  revoked,  the  CA publishes  one  or  more  CRLs to  show  all  certificates  that  have 
been  revoked.  The  CRLs  contain  the  serial  numbers  of  all  revoked  certificates and provide an  effective 
way for checking the validity of certificates. 
A  CA might publish  multiple  CRLs  when  the  number  of  revoked  certificates  is  so  large  that  publishing 
them  in  a  single  CRL might degrade  network  performance. A  CA uses  CRL  distribution  points  to  indicate 
the URLs of these CRLs.  
 CA policy 
A  CA  policy  is  a  set  of  criteria  that  a  CA  follows  in processing  certificate  requests,  issuing  and  revoking 
certificates,  and  publishing  CRLs.  Usually,  a  CA  advertises  its  policy  in  the  form  of  certification  practice  
						

							 
188 
statement  (CPS). A  CA  policy can  be  acquired  through  out-of-band  means  such  as  phone,  disk,  and 
email. As different  CAs might use  different  methods  to  check  the  binding  of  a  public  key  with  an  entity, 
make sure that you understand the CA policy before selecting a trusted CA for certificate request. 
PKI architecture 
A PKI system consists of entities, a CA, a registration authority (RA), and a PKI repository. 
Figure 54 PKI architecture 
 
 
 Entity 
An  entity  is  an  end  user  of  PKI  products  or  services,  such  as  a  person,  an  organization,  a  device  like  a 
router or a switch, or a process running on a computer.  
 CA 
A  CA  is  a trusted authority responsible  for  issuing  and  managing  digital  certificates.  A  CA  issues 
certificates,  specifies  the  validity  periods of  certificates, and  revokes  certificates as  needed  by  publishing 
CRLs.  
 RA 
A  registration  authority  (RA)  is  an  extended part  of a CA  or  an  independent  authority. An RA  can 
implement functions including identity authentication, CRL management, key pair generation and key pair 
backup.  The  PKI  standard  recommends  that  an  independent  RA  be  used  for  registration  management  to 
achieve higher security.  
 PKI repository 
A  PKI  repository can  be a Lightweight Directory Access Protocol  (LDAP)  server or a common  database. It 
stores and manages information like certificate requests, certificates, keys, CRLs and logs while providing 
a simple query function. 
LDAP  is  a  protocol  for  accessing  and  managing  PKI  information.  An  LDAP  server  stores  user  information 
and  digital  certificates  from  the  RA  server  and  provides  directory  navigation  service.  From  an  LDAP 
server, an entity can retrieve local and CA certificates of its own as well as certificates of other entities.  
PKI applications 
The  PKI  technology  can  satisfy  the  security  requirements  of  online  transactions.  As  an  infrastructure,  PKI 
has a wide range of applications. Here are some application examples. Certificate
/CRL repository
Entity
RA
CA
PKI user
PKI management authorities
Issue a certificate
Issue a certificate/CRL  
						

							 
189 
 VPN 
A  virtual  private  network  (VPN)  is  a private data  communication  network  built on the  public 
communication infrastructure. A VPN can leverage network layer security protocols—for example, IPsec—
in conjunction with PKI-based encryption and digital signature technologies for confidentiality. 
 Secure email 
Emails require confidentiality, integrity, authentication, and non-repudiation. PKI can address these needs. 
The  secure  email  protocol  that  is  developing  rapidly  is Secure/Multipurpose  Internet Mail Extensions 
(S/MIME), which is based on PKI and allows for transfer of encrypted mails with signature. 
 Web security 
For web  security,  two  peers  can  establish  an SSL  connection  first  for  transparent  and  secure 
communications  at  the  application  layer.  With  PKI,  SSL  enables encrypted communications  between  a 
browser  and  a  server.  Both of the  communication  parties  can verify each  other’s identity  through  digital 
certificates. 
How does PKI work 
In a PKI-enabled network, an entity can request a local certificate from the CA and the device can check 
the validity of certificates. Here is how it works: 
1. An entity submits a certificate request to the RA. 
2. The RA reviews the identity of the entity and then sends the identity information and the public key 
with a digital signature to the CA.  
3. The CA verifies the digital signature, approves the application, and issues a certificate. 
4. The RA receives the certificate from the CA, sends it to the LDAP server to provide directory 
navigation service, and notifies the entity that the certificate is successfully issued. 
5. The entity retrieves the certificate. With the certificate, the entity can communicate with other entities 
safely through encryption and digital signature.  
6. The entity makes a request to the CA when it needs to revoke its certificate, and the CA approves 
the request, updates the CRLs and publishes the CRLs on the LDAP server. 
PKI configuration task list 
Complete the following tasks to configure PKI: 
Task Remarks 
Configuring an entity DN Required 
Configuring a PKI domain Required 
Submitting a PKI certificate request 
Submitting a certificate request in 
auto mode Required 
Use either approach Submitting a certificate request in 
manual mode 
Retrieving a certificate manually Optional 
Configuring PKI certificate verification Optional 
Destroying a local RSA key pair Optional 
Deleting a certificate Optional  
						

							 
190 
Task Remarks 
Configuring an access control policy Optional 
 
Configuring an entity DN 
A  certificate  is the binding of  a  public  key  and the identity information  of  an  entity,  where  the identity 
information  is  identified  by an  entity  distinguished  name  (DN). A CA  identifies  a  certificate  applicant 
uniquely by entity DN. 
An entity DN is defined by these parameters: 
 Common name of the entity. 
 Country code of the entity, a standard 2-character code. For example, CN represents China and US 
represents the United States. 
 Fully qualified domain name (FQDN) of the entity, a unique identifier of an entity on the network. It 
consists  of  a  host  name  and  a  domain  name  and  can  be  resolved  to  an  IP  address.  For  example, 
www.whatever.com is an FQDN, where www is a host name and whatever.com a domain name. 
 IP address of the entity. 
 Locality where the entity resides. 
 Organization to which the entity belongs. 
 Unit of the entity in the organization. 
 State where the entity resides.  
 NOTE: 
The configuration of an entity DN must comply with the CA certificate issue policy. You must determine, 
for example, which entity DN parameters are mandatory and which are optional. Otherwise, certificate 
requests might be rejected.  
Follow these steps to configure an entity DN: 
To do… Use the command… Remarks 
Enter system view system-view — 
Create an entity and enter its view pki entity entity-name Required 
No entity exists by default. 
Configure the common name for 
the entity common-name name 
Optional 
No common name is specified by 
default. 
Configure the country code for the 
entity country country-code-str 
Optional 
No country code is specified by 
default. 
Configure the FQDN for the entity fqdn name-str Optional 
No FQDN is specified by default. 
Configure the IP address for the 
entity ip ip-address 
Optional 
No IP address is specified by 
default.