Explain how user and server authentication is used to provide network security.
User and server authentication
A principal feature of network security is user authentication, which ensures that only authorized people can access protected data.
For example, how does your credit card company know it is you trying to access your online credit card statement? In turn, how can you verify
you have reached the credit card company's actual Web site and not a fraud's? User authentication is a system that meets that challenge by
typically involving a check of the user ID and password. Because of changes in individuals' access needs (as a result of hiring and resignations, for example), a user authentication system must be continually maintained in order to:
Set up access for new users
Delete former users
At the same time, a user wants to be sure that sensitive data sent to a server, such as a credit card number, goes to the intended destination.
The process that ensures sensitive data goes only to the intended receiver is called server authentication.
Root certifications and server certificates
The certificate authority creates keys by assigning each user or server a certificate that can be exchanged at the authority's certificate
server for a public key. The figure below illustrates user authentication by means of this key creation process.
User Authentication by an SSL-enabled Server
The diagram above explains digital certificate authentication using public key infrastructure (PKI), commonly applied in secure communication protocols like HTTPS.
John Smith's Certificate:
John Smith's public key
Certificate's serial number
Certificate's validity period
John Smith's Domain Name
Issuer's Domain Name
Issuer's digital signature
Verification Steps:
Does user's public key validate the issuer's digital signature?
Is today's date within the certificate's validity period?
Is the issuing Certificate Authority (CA) trusted?
Does the issuing CA's public key validate its digital signature?
Is the user's certificate listed in the directory?
Diagram Elements:
John Smith's Certificate (on the left): This contains John Smith’s public key and other identification details like domain name, certificate validity, and the issuer's information.
Issuing Certificate Authority’s Certificate (on the right): This includes the issuer’s public key, domain name, and the issuer’s digital signature. This is important for verifying if John Smith's certificate was signed by a trusted authority.
Validation Process:
The server verifies John Smith’s public key using the digital signature.
The server checks if the certificate is still within its validity period.
The issuing authority of the certificate must be a trusted entity (found in the server’s list of trusted CAs).
The server validates the issuer’s signature using its public key.
Finally, the system verifies that John Smith’s certificate is listed in a directory server to confirm his identity.
This process outlines how certificates are validated in digital communication, ensuring that both the user and the certificate authority are legitimate and that the communication is secure.
The following section contains an explanation for the interaction between Issuing Certificate Authority and Server Domain.
Server Authentication
During the SSL handshake, the server sends the client a certificate to authenticate itself.
The client uses the certificate to authenticate the identity the certificate claims to represent.
An SSL-enabled client goes through these steps to authenticate a server's identity: 1.Is today's date within the validity period?
The client checks the server certificate's validity period. If the current date and time are outside of that range, the authentication process does not go any further. If the current date and time are within the certificate's validity period, the client goes on to step
Is the issuing Certificate Authority (CA) a trusted CA?
Each SSL-enabled client maintains a list of trusted CA certificates. This list determines which server certificates the client will accept. If the distinguished name (DN) of the issuing CA matches the DN of a CA on the client's list of trusted CAs, the answer to this question is yes, and the client goes on to step 3. If the issuing CA is not on the list, the server is not authenticated unless the client can verify a certificate chain ending in a CA that is on the list.
Does the issuing CA's public key validate the issuer's digital signature? The client uses the public key from the CA's certificate (which it found in its list of trusted CAs in step 2) to validate the CA's digital signature on the server certificate that is being presented. If the information in the server certificate has changed since it was signed by the CA,
or if the CA certificate's public key doesn't correspond to the private key that was used by the CA to sign the server certificate, the client does not authenticate the server's identity. If the CA's digital signature can be validated, the client treats the server's certificate as a valid "letter of introduction" from that CA and proceeds. At this point, the client has determined that the server certificate is valid.
It is the client's responsibility to take step 4 before it takes step 5.
Does the domain name in the server's certificate match the domain name of the server itself?
This step confirms that the server is actually located at the same network address that is specified by the domain name in the server certificate.
Although step 4 is not technically part of the SSL protocol, it provides the only protection against a form of security attack known as a "Man-in-the-Middle Attack." Clients must perform this step and must refuse to authenticate the server or establish a connection if the domain names do not match. If the server's actual domain name matches the domain name in the server certificate, the client goes on to step 5.
The server is authenticated: The client proceeds with the SSL handshake. If the client does not get to step 5 for any reason, the server that is identified by the certificate cannot be authenticated,
and the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established.
Servers public key and certificates serial number
The image you uploaded explains server authentication in a secure communication environment, likely using public key infrastructure (PKI), which is commonly applied in HTTPS.
Server's Certificate:
Server’s public key
Certificate’s serial number
Certificate’s validity period
Server’s Domain Name
Issuer’s Domain Name
Issuer’s digital signature
Verification Steps:
Is today’s date within the validity period?
Is the issuing Certificate Authority a trusted Certificate Authority?
Does the issuing Certificate Authority’s public key validate the issuer’s digital signature?
Does the Domain Name specified in the server’s Domain Name match the server’s actual domain name?
Diagram Elements:
Server's Certificate (on the left): Contains the server’s public key, domain name, the certificate’s validity period, and the issuer’s digital signature, which verifies that the certificate was issued by a trusted Certificate Authority (CA).
Issuing Certificate Authority (on the right): This shows the issuer’s domain name, public key, and the issuer's digital signature. The issuer’s public key is used to verify the digital signature on the server's certificate.
Verification Process:
The client checks if the server’s certificate is still valid based on its validity period.
The client verifies if the Certificate Authority (CA) that issued the server’s certificate is trusted, typically by referring to a list of trusted CAs.
The client validates the issuer’s digital signature using the issuer’s public key to ensure that the server’s certificate was signed by a legitimate authority.
Finally, the client checks if the domain name in the server’s certificate matches the actual domain name being accessed.
This process is crucial for establishing secure communication between a client (like a web browser) and a server, ensuring that the server is legitimate and the connection is secure.
Is today's date within the validity period?
Is issuing Certificate Authority a trusted certificate authority?
Does issuing Certificate Authority's public key validate issuers digital signature?
Does the Domain Name specified in the server's Domain Name match the server's actual domain name?
In the next lesson, you will learn about the different security requirements for the Internet, intranets, and extranets.
