[Dr.WoW] [No.37] Digital Certificate Authentication Highlighted

Latest reply: Oct 5, 2015 16:50:51 3015 2 0 0

For each additional sub-host, the host must configure a pre-shared key for each peer formed for each sub-host. If all peers used the same key, there is a glaring security risk; if each peer uses a different key, it will be hard to administer and maintain the network. As such, Tiandihui urgently required a new identity message authentication scheme to replace the pre-shared key method and lower administration costs. Since Tiandihui's hosts and sub-hosts were all under the guise of legitimate businesses (i.e. shop-owners and buyers), they might as well directly apply to the government's Penal Bureau for shop-owner and buyer identity vouchers to market their respective identity messages as shop-owner and buyer. Because the Penal Bureau is a fair and reliable government authority, identity vouchers stamped by the Penal Bureau can also be trusted; in this way, hosts and sub-hosts can directly authenticate their respective identities with these identity vouchers.

This identity voucher, known as a digital certificate or simply a certificate, is an "ID card" that serves as a device identity message issued by third-party organizations. By introducing this certificate function, the host and sub-host s can simply and easily perform identity authentication. For a further introduction to certificates, see "Appendix B Certificate ***ysis".

Before we discuss the certificate implementation principles and methods of retrieval, we first must understand public key cryptology and PKI profiles.

1 Public Key Cryptology and PKI Profiles

In section "IPSec Overview", we mentioned symmetric cryptology, in which the host and sub-hosts use the same key for encryption and decryption. Conversely, asymmetric cryptology is when encryption and decryption data uses different keys; this is also known as public key cryptology. Currently, the more commonly used public key cryptology algorithms are RSA (Ron Rivest, Adi Shamirh, LenAdleman) and DSA (Digital Signature Algorithm).

In public key cryptology, two different keys are used: one key, available to the public, is known as the "public key"; conversely, the key only known to its owner is the "private key". What's unique about this set of keys is that the message used to encrypt the public key can only be used to decrypt the corresponding private key; conversely, the message used to encrypt the private key can only be used to decrypt the corresponding public key.

By utilizing this special feature, mutual identity authentication is possible. For instance, suppose a certain sub-host firewall uses its own private key for message encryption (digital signature); the host firewall will then use the sub-host firewall's publicly available public key for decryption. Because others don't know the sub-host firewall's private key, only when the host uses the corresponding public key can the message be decrypted, thereby confirming that the message was sent by the sub-host - thus completing identity authentication.

Now that we understand the basic concept of public key cryptology, how then are these concepts put to use in our actual environment? PKI (Public Key Infrastructure) is a basic profile based on public key cryptology that is used for message security services; the digital certificate is a core component of this profile, and IKE borrows the PKI certificate function to perform peer identity authentication.

A PKI profile will include the following two major characters:

l   End Entity (EE): the certificate end user, such as the host and sub-host firewalls.

l   Certificate Authority (CA): an authoritative, trusted third-party organization (similar to the Imperial Penal Bureau), responsible for issuing, querying and updating certificates and other such tasks.

In an IPSec, the host and sub-host firewalls are the certificate end users. If we want to generate a certificate for a firewall, we must first guarantee that the firewall has its own private-public key pair. We can create a private-public key pair on the host and sub-host firewalls and then send the public key and firewall messages (entity messages) to the CA for certificate application; private-public key pairs can also be generated on the CA for the host and sub-host, and on this basis, a certificate can be generated as well; the host and sub-host firewalls will then import their own respective private-public key pairs and certificates. In this section, we will mainly discuss host and sub-host firewall self-created private-public key pairs and the certificate that they use; for the CA host and sub-host firewall private-public key pair and certificate generation process, see "Appendix B Certificate ***ysis".

NOTE: All certificates mentioned herein can be divided into two categories: firewall certificates known as local certificates which serve as the firewall identity and CA "signature-based" certificates known as CA certificates or root certificates which serve as the CA identity.

We've just briefly introduced some of the major concepts about certificates. Next, let's take a look at how host and sub-host firewalls obtain such certificates.

2 Certificate Applications

Before host and sub-host firewalls can apply a certificate, they must first generate a private-public key pair. Then, the public key and firewall entity messages shall be given to the CA, and the CA will generate a certificate based on these messages. The host and sub-host firewalls can apply for certificates through the following two methods:

l   Online method (in-band method)

The firewall and CA exchange packets through the certificate application protocol for an online certificate application. The certificate applied for will be directly saved to the firewall's storage device (Flash or CF card); common certificate application protocols include SCEP (Simple Certification Enrollment Protocol) and CMP (Certificate Management Protocol). This method is suitable for firewalls that support SCEP or CMP and also depends on the network connectivity between the firewall and CA.

l   Offline method (out-of-band method)

First, the firewall will generate a certificate request (the contents of which include the public key and entity message); we'll then send these documents to the CA on a disk, via email or other such methods. Then, the CA will formulate a certificate for the firewall based on the certificate request and the certificate will be returned in the same way, on a disk, via email or through other such methods. Lastly, we will transfer the certificate to the firewall storage device. This method is suitable for firewalls that do not support SCEP or CMP, or when there is no network connectivity between the firewall and CA.

These two methods can be chosen flexible based on the actual firewall situation. Next, we will use the offline method and the networking environment as shown in Figure 1-1 to illustrate the process by which the host and sub-host firewalls retrieve certificates.

Figure 1-1 IKE/IPSec networking

[Dr.WoW] [No.37] Digital Certificate Authentication-1271503-1

 

The offline certificate application process is as shown in Figure 1-2.

Figure 1-2 Offline certificate application process

[Dr.WoW] [No.37] Digital Certificate Authentication-1271503-2

 

1.         Create private-public key pair

First, respective private-public key pairs are created on FW_A and FW_B to be used in the public key message when applying for the certificate. In the process, the system will prompt for the public key number; the length of the number will range from 512 to 2048. The longer the length of the public key, the higher its security; however, in terms of computing speeds, longer keys take longer to process. Here, we need maximum security, so we'll enter 2048.

Create private-public key pair on FW_A:

[FW_A] rsa local-key-pair create

The key name will be: FW_A_Host

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512.

 It will take a few minutes.

Input the bits in the modulus[default = 512]: 2048

Generating keys...

.................................................+++

...............................................+++

..............++++++++

.++++++++

Create private-public key pair on FW_B:

[FW_B] rsa local-key-pair create

The key name will be: FW_B_Host

The range of public key size is (512 ~ 2048).

NOTES: If the key modulus is greater than 512.

 It will take a few minutes.

Input the bits in the modulus[default = 512]: 2048

Generating keys...

.................................................+++

...............................................+++

..............++++++++

.++++++++

2.         Configure entity message

When applying for the certificate, FW_A and FW_B must provide sufficient messages to the CA to verify their identities; entity messages serve as identity messages for firewalls, such as: CN (Common Name), FQDN (Fully Qualified Domain Name) name, IP address, email address, etc. Of these messages, the CN must be configured, while the configuration of other items is optional.

These messages must be included in the certificate, and when configuring the ID type on the IKE peer, the ID type to be used for authentication can be determined based on the entity messages included in the certificate.

Once the entity messages are configured, they must also be cited in the PKI domain. Table 1-1 lays out the configuration of FW_A and FW_B entity messages and PKI domains.

Table 1-1 Configuration entity and PKI

Key Configuration

Host FW_A

Sub-Host FW_B

Entity Message

pki entity fwa

 common-name fwa //CN

fqdn fwa.tdh.com //FQDN name

ip-address 1.1.1.1 //IP address

email fwa@tdh.com //Email address

pki entity fwb

 common-name fwb //CN

fqdn fwb.tdh.com //FQDN name

ip-address 3.3.3.3 //IP address

email fwb@tdh.com //Email address

PKI domain

pki domain fwa

certificate request entity fwa //PKI domain cited entity message

pki domain fwb

certificate request entity fwb //PKI domain cited entity message

 

3.         Generate certificate request

Next, we can generate the certificate request on FW_A and FW_B. The generated certificate request can be saved on the FW_A and FW_B storage devices under the name "PKIdomainname.req". The name of the certificate request generated on FW_A is fwa.req, while the name of the certificate request generated on FW_B is fwb.req.

[FW_A] pki request-certificate domain fwa pkcs10

Creating certificate request file...

Info: Certificate request file successfully created.

[FW_B] pki request-certificate domain fwb pkcs10

Creating certificate request file...

Info: Certificate request file successfully created.

By checking the certificate request generated on FW_A, you can see that it will include the configured CN, FQDN name, IP address, and email address, as well as the FW_A public key message.

[FW_A] display pki cert-req filename fwa.req

Certificate Request:

 Data:

 Version: 0 (0x0)

 Subject: CN=fwa

 Subject Public Key Info:

 Public Key Algorithm: rsaEncryption

 RSA Public Key: (2048 bit)

 Modulus (2048 bit):

 00: ae: 68: 50: 18: e7: 55: 32: 7a: 0e: 61: b6: 6e: 47: 45:

 ec: fb: 29: d9: 1b: 4a: 9d: 6b: b0: 00: b0: 65: c8: fc: 5b:

 b4: 68: d7: 90: 7d: 96: f7: 1d: e4: 62: 43: 06: bc: d0: a3:

 5b: b4: fa: 30: a3: 19: 7e: 6f: 7c: 05: 6b: 47: 0c: a2: 42:

 1b: c4: 82: f7: 5b: 0a: 73: a1: 0a: 8b: 00: dd: 37: aa: 5e:

 21: 02: 56: b2: e6: 55: 31: 08: 8f: 71: 03: 13: 92: b9: c1:

 51: 7e: 51: 04: e2: ca: 85: 2e: 45: 97: bb: 9a: 0e: ed: 61:

 03: 97: d2: 1e: 44: b2: 9f: ff: b9: b1: 1d: 5d: 65: 7e: fc:

 e6: 13: c3: 1e: 71: 81: d0: fe: a0: 60: 71: a4: 8a: 40: 93:

 92: e3: b3: b6: cf: 56: f1: 30: b2: fc: 53: 31: bd: 9d: 6f:

 3c: 33: 1e: 4a: a5: 6f: 83: c7: 45: 26: 8d: c6: 9c: 84: 85:

 b5: 8f: b9: e3: 86: 86: 59: ad: 9b: 58: 63: a1: 3d: 7b: 81:

 d7: 43: 14: 3d: 98: 4a: a2: cb: 82: 2c: fa: ca: 91: 32: b1:

 e0: 09: de: fa: a8: d6: fc: ea: 8e: 7e: 36: 8f: fb: 86: 31:

 1e: bc: 5e: 01: 71: 6b: b4: 23: 86: 7b: 05: c1: 63: 7a: f5:

 bc: a7: 9b: a1: da: ff: 4f: 26: 2d: 33: 44: 06: 72: f1: 7b:

 84: d5: a8: 49: 1d: be: b4: 0e: 9c: 94: 85: 34: 7b: e5: bb:

 8a: 49

 Exponent: 65537 (0x10001)

 Attributes:

 Requested Extensions:

 X509v3 Subject Alternative Name:

 IP Address: 1.1.1.1. DNS: fwa.tdh.com, email: fwa@tdh.com

 Signature Algorithm: md5WithRSAEncryption

 4b: a6: fc: 91: 2a: 77: e3: 30: 02: bb: e4: 0f: 1a: bf: d2: a1: ad: 81:

 3e: 44: 51: 81: b1: 26: 2d: 2e: 83: 7c: 0c: 29: 70: 3c: 6a: 8a: 7a: 1a:

 27: c8: a4: 8d: 3b: 8f: dc: a7: d7: df: 10: be: 4c: 96: 1f: f5: db: 96:

 4d: e9: 28: 82: b9: 2d: 9b: e6: 6d: 22: 52: ca: 50: 07: c2: 7a: 2b: 17:

 c7: 49: 7a: a6: a5: 7c: cc: 82: 02: 15: 14: ca: 9c: 69: 39: eb: fb: 44:

 3a: c9: 75: d9: f5: b6: bf: b1: 45: e4: e7: f4: db: df: eb: 3d: 6b: 74:

 ac: 14: e9: 51: af: b1: c8: d6: c1: 19: 48: bc: 27: c1: 37: 59: 41: 38:

 9c: 1f: 9a: 7e: c7: fe: 20: c9: e8: 1d: 94: 55: ff: 85: 3e: 8c: 5a: f5:

 f3: ff: 9b: 18: 36: b1: 25: 2b: 4d: 60: 2e: 13: 7b: be: 91: c0: a1: 1f:

 6c: 5c: 1a: f6: 3a: 5b: e7: 87: 2b: 43: 7f: d8: f6: 2b: c8: b1: df: 7d:

 c8: 40: df: 07: f9: 52: 4c: 8b: ba: b0: 10: f3: 34: 00: 00: 74: 0b: ae:

 c1: 7a: 9c: dd: de: 26: 26: 28: 30: de: e8: 6c: dc: 0a: c6: 8f: 27: 27:

 c6: 0d: 5e: 8e: 68: a8: 8d: cc: eb: 91: 9c: 59: 3d: 1e: f3: f3: 58: 72:

 16: bf: cc: f5: df: 71: bc: 51: fb: 98: 83: c5: 2b: 17: 73: d7: 0a: 6c:

 f7: 93: 76: f4

4.         CA formulates request based on certificate request

Once the certificate request is generated, these documents can be sent to the CA on a disk, via email or though other such methods, and the CA will formulate a certificate for FW_A and FW_B. In addition to the FW_A and FW_B certificates, the CA will also create its own certificate, i.e. the CA certificate. The CA will return the FW_A and FW_B certificates along with its own certificate on a disk, via email or through other such methods.

The commonly used Windows Server operating system can serve as a CA for generating and issuing certificates; the specific operating steps can be found through a simple online search and will not be discussed at this time.

5.         Import certificate

Once CA processing is complete, we will ultimately receive FW_A certificate fwa.cer, FW_B certificate fwb.cer, and also the CA's own certificate, ca.cer.

fwa.cer and ca.cer will be uploaded to the FW_A storage device, and fwb.cer and ca.cer will be uploaded to the FW_B storage device; afterwards, the certificate must also be respectively imported to FW_A and FW_B.

Import CA certificate and local certificate on FW_A:

[FW_A] pki import-certificate ca filename ca.cer

Info: Import file successfully.

[FW_A] pki import-certificate local filename fwa.cer

Info: Import file successfully.

Import CA certificate and local certificate on FW_B:

[FW_B] pki import-certificate ca filename ca.cer

Info: Import file successfully.

[FW_B] pki import-certificate local filename fwb.cer

Info: Import file successfully.

3 Digital Certificate Identity Authentication

Once the certificates are imported, FW_A and FW_B will both have "identitified" devices. When the certificate is cited in the IKE peer, FW_A and FW_B can authenticate the other peer's identity through the certificate.

Previously we mentioned that when certificates are used for identity authentication, the ID type can be determined based on the entity message in the certificate. Currently, for IKE peers, the four ID types of the DN (Distinguished Name), FQDN, User-FQDN and IP can be used. These four ID types correspond to the certificate text as well as the values on FW_A and FW_B, as shown in Table 1-2.

Table 1-2 Certificate identity ID text and firewall values

ID Type

Corresponding Certificate Text

FW_A Values

FW_B Values

DN

Subject

local ID: /CN=fwa

peer ID: /CN=fwb

local ID: /CN=fwb

peer ID: /CN=fwa

FQDN

DNS

local ID: fwa.tdh.com

peer ID: fwb.tdh.com

local ID: fwb.tdh.com

peer ID: fwa.tdh.com

User-FQDN

email

local ID: fwa@tdh.com

peer ID: fwb@tdh.com

local ID: fwb@tdh.com

peer ID: fwa@tdh.com

IP

IP Address

local ID: 1.1.1.1

peer ID: 3.3.3.3

local ID: 3.3.3.3

peer ID: 1.1.1.1

 

Table 1-3 illustrates the key configuration for FW_A and FW_B with the ID type of DN.

Table 1-3 IKE/IPSec certificate authentication configuration

Key Configuration

Host FW_A

Sub-Host FW_B

IKE Proposal

ike proposal 10

authentication-method rsa-sig//use certificate authentication method

ike proposal 10

authentication-method rsa-sig//use certificate authentication method

IKE Peer

ike peer fwb

certificate local-filename fwa.cer //FW_A certificate

ike-proposal 10

local-id-type dn //ID type of DN

remote-id /CN=fwb //FW_B DN

remote-address 3.3.3.3 //FW_B IP address

ike peer fwa

certificate local-filename fwb.cer //FW_B certificate

ike-proposal 10

local-id-type dn //ID type of DN

remote-id /CN=fwb //FW_A DN

remote-address 1.1.1.1 //FW_A IP address

Certificate Attribute Access Control Policy

pki certificate access-control-policy default permit

pki certificate access-control-policy default permit

 

When the certificate method is used for the IKE negotiation process, it is roughly the same as when the pre-shared key method is used. The difference between the two is that when the certificate method is used, the ISAKMP identity messages (main mode is ISAKMP message (5) and (6); aggressive mode is ISAKMP message (1) and (2)) sent between the two peers will include an additional certificate payload and signature payload. We won't go into the specifics on the negotiation process again.

At this point, Tiandihui had found an alternative identity message authentication scheme to the pre-shared key method. When new sub-hosts establish an IPSec connection to the host FW, all the sub-host needs to do is apply for a certificate with the same CA; then the sub-host and host can perform identity authentication with the certificate. Since the host does not need to protect the same pre-shared key for each sub-host, Tiandihui could reduce its administration costs.

NOTE: Apart from its use in IPSec connections, a digital certificate can also be used for identity authentication between SSL VPN clients and servers; for details, see "Chapter 7 Overview of SSL VPNs".

In addition to the surge in new sub-hosts, Tiandihui also had some older sub-hosts who had already been accessed into the host via GRE or L2TP method accession host. How can IPSec be used to ensure secure communications between these sub-hosts and the host without changing the original access mode? Dr. WoW will take us through an in-depth study on this very topic.

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

TunisiaTunisys
Created Oct 5, 2015 16:50:51 Helpful(0) Helpful(0)

thank you 

  • x
  • convention:

user_2790689
Created Aug 28, 2015 01:13:50 Helpful(0) Helpful(0)

Thank you.
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login