Documente Academic
Documente Profesional
Documente Cultură
ASSIGNMENT 02
Submitted in Partial Fulfilment of the Requirements
For the Award of degree of
MASTER OF TECHNOLOGY
(COMPUTER SCIENCE AND ENGINEERING)
TO
Authentication Protocol:
An authentication protocol is a type of computer communications
protocol or cryptographic protocol specifically designed for transfer
of authentication data between two entities. It allows the receiving entity to
authenticate the connecting entity (e.g. Client connecting to a Server) as well as
authenticate itself to the connecting entity (Server to a client) by declaring the type
of information needed for authentication as well as syntax. [1] It is the most
important layer of protection needed for secure communication within computer
networks.
Purpose
With the increasing amount of trustworthy information being accessible over the
network, the need for keeping unauthorized persons from access to this data
emerged. Stealing someone's identity is easy in the computing world - special
verification methods had to be invented to find out whether the person/computer
requesting data is really who he says he is. ] The task of the authentication protocol
is to specify the exact series of steps needed for execution of the authentication. It
has to comply with the main protocol principles:
1. A Protocol has to involve two or more parties and everyone involved in the
protocol must know the protocol in advance.
2. All the included parties have to follow the protocol.
3. A protocol has to be unambiguous - each step must be defined precisely.
4. A protocol must be complete - must include a specified action for every
possible situation.
An illustration of password-based authentication using simple authentication
protocol:
Alice (an entity wishing to be verified) and Bob (an entity verifying Alice's
identity) are both aware of the protocol they agreed on using. Bob has Alice's
password stored in a database for comparison.
1. Alice sends Bob her password in a packet complying with the protocol rules.
2. Bob checks the received password against the one stored in his database.
Then he sends a packet saying "Authentication successful" or
"Authentication failed" based on the result.
This is an example of a very basic authentication protocol vulnerable to many
threats such as eavesdropping, replay attack, man-in-the-middle attacks, dictionary
attacks or brute-force attacks. Most authentication protocols are more complicated
in order to be resilient against these attacks.
TYPES:
Authentication protocols developed for PPP Point-to-Point Protocol
Protocols are used mainly by Point-to-Point Protocol (PPP) servers to validate the
identity of remote clients before granting them access to server data. Most of them
use a password as the cornerstone of the authentication. In most cases, the
password has to be shared between the communicating entities in advance.
PAP 2-way handshake scheme
Protocol:
Description
The client authenticates itself to the Server (AS) which forwards the username to
a key distribution center (KDC). The KDC issues a ticket-granting ticket (TGT),
which is time stamped and encrypts it using the ticket-granting service's
(TGS) secret key and returns the encrypted result to the user's workstation. This is
done infrequently, typically at user logon; the TGT expires at some point although
it may be transparently renewed by the user's session manager while they are
logged in.
When the client needs to communicate with a service on another node (a
"principal", in Kerberos parlance), the client sends the TGT to the TGS, which
usually shares the same host as the KDC. Service must be registered at TGS with
a Service Principal Name (SPN). The client uses the SPN to request access to this
service. After verifying that the TGT is valid and that the user is permitted to
access the requested service, the TGS issues ticket and session keys to the client.
The client then sends the ticket to the service server (SS) along with its service
request.
Kerberos negotiations
The protocol is described in detail below.
User Client-based Login
1. When requesting services, the client sends the following messages to the
TGS:
o Message C: Composed of the TGT from message B and the ID of the
requested service.
o Message D: Authenticator (which is composed of the client ID and the
timestamp), encrypted using the Client/TGS Session Key.
2. Upon receiving messages C and D, the TGS retrieves message B out of
message C. It decrypts message B using the TGS secret key. This gives it
the "client/TGS session key". Using this key, the TGS decrypts message D
(Authenticator) and compare client ID from message C and D, if they match
server sends the following two messages to the client:
o Message E: Client-to-server ticket (which includes the client ID, client
network address, validity period and Client/Server Session Key)
encrypted using the service's secret key.
o Message F: Client/Server Session Key encrypted with the Client/TGS
Session Key.
Client Service Request
1. Upon receiving messages E and F from TGS, the client has enough
information to authenticate itself to the Service Server (SS). The client
connects to the SS and sends the following two messages:
o Message E: from the previous step (the client-to-server ticket, encrypted
using service's secret key).
o Message G: a new Authenticator, which includes the client ID,
timestamp and is encrypted using Client/Server Session Key.
2. The SS decrypts the ticket (message E) using its own secret key to retrieve
the Client/Server Session Key. Using the sessions key, SS decrypts the
Authenticator and compares client ID from messages E and G, if they match
server sends the following message to the client to confirm its true identity
and willingness to serve the client:
o Message H: the timestamp found in client's Authenticator (plus 1 in
version 4, but not necessary in version 5), encrypted using
the Client/Server Session Key.
3. The client decrypts the confirmation (message H) using the Client/Server
Session Key and checks whether the timestamp is correct. If so, then the
client can trust the server and can start issuing service requests to the server.
4. The server provides the requested services to the client.
Vulnerabilities
The Data Encryption Standard (DES) cipher can be used in combination with
Kerberos, but is no longer an Internet standard because it is weak. [8] Security
vulnerabilities exist in many legacy products that implement Kerberos because
they have not been updated to use newer ciphers like AES instead of DES.
In the X.509 system, an organization that wants a signed certificate requests one via
a certificate signing request (CSR).
To do this, it first generates a key pair, keeping the private key secret and using it to
sign the CSR. This contains information identifying the applicant and the
applicant's public key that is used to verify the signature of the CSR - and
the Distinguished Name (DN) that the certificate is for. The CSR may be
accompanied by other credentials or proofs of identity required by the certificate
authority.
The certification authority issues a certificate binding a public key to a
particular distinguished name.
An organization's trusted root certificates can be distributed to all employees so that
they can use the company PKI system. Browsers such as Internet
Explorer, Firefox, Opera, Safari and Chrome come with a predetermined set of root
certificates pre-installed, so SSL certificates from major certificate authorities will
work instantly; in effect the browsers' developers determine which CAs are trusted
third parties for the browsers' users. For example, Firefox provides a CSV and/or
HTML file containing a list of Included CAs.
X.509 and RFC 5280 also include standards for certificate revocation list (CRL)
implementations. Another IETF-approved way of checking a certificate's validity is
the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by
default, as do versions of Windows from at least Vista and later. [3]
Structure of a certificate
The structure foreseen by the standards is expressed in a formal language, Abstract
Syntax Notation One (ASN.1).
The structure of an X.509 v3 digital certificate is as follows:
Certificate
o Version Number
o Serial Number
o Signature Algorithm ID
o Issuer Name
o Validity period
Not Before
Not After
o Subject name
o Subject Public Key Info
Public Key Algorithm
Subject Public Key
o Issuer Unique Identifier (optional)
o Subject Unique Identifier (optional)
o Extensions (optional)
...
Certificate Signature Algorithm
Certificate Signature
Each extension has its own ID, expressed as object identifier, which is a set of
values, together with either a critical or non-critical indication. A certificate-using
system must reject the certificate if it encounters a critical extension that it does not
recognize, or a critical extension that contains information that it cannot process. A
non-critical extension may be ignored if it is not recognized, but must be processed
if it is recognized.
The structure of version 1 is given in RFC 1422.
ITU-T introduced issuer and subject unique identifiers in version 2 to permit the
reuse of issuer or subject name after some time. An example of reuse will be when
a CA goes bankrupt and its name is deleted from the country's public list. After
some time, another CA with the same name may register itself, even though it is
unrelated to the first one. However, IETF recommends that no issuer and subject
names be reused. Therefore, version 2 is not widely deployed in the Internet.
Extensions were introduced in version 3. A CA can use extensions to issue a
certificate only for a specific purpose (e.g. only for signing digital objects).
In all versions, the serial number must be unique for each certificate issued by a
specific CA (as mentioned in RFC 5280).
Extensions informing a specific usage of a certificate
RFC 5280 (and its predecessors) defines a number of certificate extensions which
indicate how the certificate should be used. Most of them are arcs from the joint-
iso-ccitt(2) ds(5) id-ce(29) OID. Some of the most common, defined in section
4.2.1, are:
Basic Constraints, { id-ce 19 }, are used to indicate whether the certificate
belongs to a CA.
Key Usage, { id-ce 15 }, provides a bitmap specifying the cryptographic
operations which may be performed using the public key contained in the
certificate; for example, it could indicate that the key should be used for
signatures but not for encipherment.
Extended Key Usage, { id-ce 37 }, is used, typically on a leaf certificate, to
indicate the purpose of the public key contained in the certificate. It contains a
list of OIDs, each of which indicates an allowed use. For example, { id-pkix 3 1
} indicates that the key may be used on the server end of a TLS or SSL
connection; { id-pkix 3 4 } indicates that the key may be used to secure email.
In general, if a certificate has several extensions restricting its use, all restrictions
must be satisfied for a given use to be appropriate. RFC 5280 gives the specific
example of a certificate containing both keyUsage and extendedKeyUsage: in this
case, both must be processed and the certificate can only be used if both extensions
are coherent in specifying the usage of a certificate. For example, NSS uses both
extensions to specify certificate usage.
Pretty Good Privacy uses a variation of the public key system. In this system, each
user has an encryption key that is publicly known and a private key that is known only
to that user. You encrypt a message you send to someone else using their public key.
When they receive it, they decrypt it using their private key. Since encrypting an
entire message can be time-consuming, PGP uses a faster encryption algorithm to
encrypt the message and then uses the public key to encrypt the shorter key that was
used to encrypt the entire message. Both the encrypted message and the short key are
sent to the receiver who first uses the receiver's private key to decrypt the short key
and then uses that key to decrypt the message.
PGP comes in two public key versions -- Rivest-Shamir-Adleman (RSA) and Diffie-
Hellman. The RSA version, for which PGP must pay a license fee to RSA, uses
the IDEA algorithm to generate a short key for the entire message and RSA to encrypt
the short key. The Diffie-Hellman version uses the CAST algorithm for the short key
to encrypt the message and the Diffie-Hellman algorithm to encrypt the short key.
When sending digital signatures, PGP uses an efficient algorithm that generates
a hash (a mathematical summary) from the user's name and other signature
information. This hash code is then encrypted with the sender's private key. The
receiver uses the sender's public key to decrypt the hash code. If it matches the hash
code sent as the digital signature for the message, the receiver is sure that the message
has arrived securely from the stated sender. PGP's RSA version uses
the MD5 algorithm to generate the hash code. PGP's Diffie-Hellman version uses the
SHA-1 algorithm to generate the hash code.