AUTHTENTICATION SERVICEPROVIDEDBY X.
509
STANDARD
ITU-T (International Telecommunication Union) recommends X.500 series for keeping
and maintaining user’s information in a directory (or server).
X.509 is part of X.500 recommendations. It considers use of public key (or asymmetric)
cryptography and digital signatures.
X.509 assumes presence of X.500 directory (repository) that keeps public key
certificates of users.
User ID Encrypt using CA’s Append
Calculated private key (encrypted signature to
User public Hash code hash code becomes certificate
key signature)
Certificate
User ID
User public
key
Signature can be verified using CA’s Public key Signature
Signed certificate
Fig 1Public key certificate generation
Signing
Version
Certificate
algorithm
identifier { Algorithm &
Parameters
Serial number
Issuer name
Signing
algorithm
{ Algorithm &
Parameters Creation date
All Version
identifier
Issuer name Future updation date
Validity
duration { Not before
Not after
Revoked
certificate { User certificate serial no
Revocation date
.
Subject name .
.
Public-key
info of
{ Algorithms,
Parameters &
Revoked
{ User certificate serial no
version 2 & 3
certificate Revocation date
Common to
subject Key
Issuer/Subject unique
Identifier
Signature
{
version 3
Only in
Extensions
(b) Certificate revocation list
{
versions
Algorithms &
All
Signature Parameters
Encrypted
(a) X.509 certificate
Fig 2X.509 Certificate Format
A public key certificate of a user contains public key of user digitally signed by private
key of trusted third party (termed as certification authority (CA)).
Based upon public key certificates, X.509 standard (framework) provides authentication
protocols for ensuring authentication services.
The X.509 based authentication protocols are used in many situations and protocols like
S/MIME, IP security, SET etc.
Among several public key algorithms, X.509 recommends RSA.
The X.509 framework rest heavily upon public key certificates. These certificates are
created by Certifying Authority (CA) and placed in the directory. Thus, for sharing a
certificate either directory service is used or certificate is distributed by the owner to the
communicating user.
Figure 1 – shows steps involved in generation of a public key certificate by CA.The
certificate containing user (subject) details along with public key is digitally signed by
CA i.e., the hash of certificate is calculated and then encrypted using private key of CA.
The digital signatures are appended to certificate (Figure 2 shows the general format and
components of X.509 certificate). The components constituting a certificate are as
follows:
Version – Indicates the version of certificate format. Three versions 1, 2 and 3
are there with version 1 as the default. Two unique identifiers namely issuer
unique identifier and subject unique identifier were added in version 2 while
extensions were added in version 3.
Serial number- A unique integer value assigned by CA identifying the certificate.
This value remains unique within a CA.
Signature algorithm identifier- Indicates the signing algorithm along with
associated parameters.
Issuer name- Name of CA that issues the certificate.
Period of validity – Indicates the certificate validity period (in terms of two
dates: Not Before and Not After) in which it can be used.
Subject name – Certificate owner’s name whose public key is contained in the
certificate and who has corresponding private key.
Subject public key information - Owner’s public key along with algorithm
identifier and associated parameters indicating that this public key can be used
with corresponding algorithm.
Optional unique identifiers for issuer and subject – To uniquely identify the
issuer and subject (version 2). Though these are rarely used, they provide reuse
of issuer and subject identifiers over time.
Extensions – Provided in version 3, consists of number of optional extensions
where each extension has an identifier, criticality indicator and value for that
extension. A criticality indicator with TRUE value implies that the extension
cannot be ignored and if its recognition is not possible then the entire certificate
is treated as invalid.
These extensions correspond to the following three categories:
(i) Extensions conveying additional information regarding keys (of both issuer
and subject) and certificate policy. Such information includes public key
usage indication (e.g., digital signature, key encryption, data encryption etc.),
private key validity period indication, certificate policy listing and mapping.
(ii) Extensions indicating alternative names and formats of subject and issuer.
(iii)Extensions implying constraint specifications for issuing certificates by CA
for other CAs i.e., for certificates lying in certification chain.
Signature – Digital signature (i.e., hash encrypted using CA’s private key)
created for certificate.
A digital certificate ensures the following:
(i) A user who possesses the CA’s public key can verify the certificate and hence
public key of the user contained within.
(ii) Modification to certificate by a party other than CA is not possible.
Both (i) & (ii) mean that certificates are unforgeable and can be kept in directory as such
without protection.
For obtaining other user’s certificate by a user, two cases are there.
(i) Case 1: Users lie under same CA – in this case both of them (one who requires
certificate, other whose certificate is required) trust same CA and hence can
share their certificates directly. They can verify each other’s certificate using
public key of CA.
(ii) Case 2: Users lie under different CAs- in this case each user trust its own CA and
is able to verify the certificates using public key of CA.
In case (ii) above, A is able to read the certificateB (issued by CA2 to B) but
cannot verify it directly due to lack of public key of CA2.
Thus, A follows following procedure:
(1) A obtains certificateCA2 (CA1<<CA2>>) i.e., certificate of CA2 issued by
CA1 from the directory. As A has public key of CA1, from this certificate
A can verify and extract public key of CA2.
(2) Using this public key A can now verify the certificateB (CA2<<B>>)
issued by CA2 and can extract public key of B.
X.509 expresses this chain as
CA1<<CA2>>CA2<<B>>**
Note: **notation Y<<X>> implies certificate X issued by CA Y
Similarly, B can obtain public key of A (step 3 & 4 (Figure 9.13))
1 CertificateCA2 (CA1<<CA2>>)
CA1
3 CA2
CertificateCA1 (CA2<<CA1>>)
4 2
CertificateA CertificateB(
A (CA1<<A>>) B CA2<<B>>)
Figure 3 Obtaining of digital certificate by users
In general, for N CAs certifying chain can be expressed as:
CA1<<CA2>>CA2<<CA3>>-----CAN<<B>>
Each of CA (CAi) creates certificates for each other and these certificates lie in the
directory from where user can learn the linkages.
X.509 favors hierarchical arrangement of CAs for better navigation in certifying chain.
In Figure 4 user R can obtain the certificates from directory*** to build the certifying
chain (path) to U as:
P<<L>>L<<K>>K<<M>>M<<Q>>Q<<U>>
Thus, R can unwind this sequence to obtain public key of U
*** U can also provide these certificates to R in initial message exchanges.
K-Node
L-Node
M-Node
K<<L>>
K<<M>>
L<<K>>
M<<K>>
P-Node Q-Node
L<<P>> M<<Q>>
P<<L>> Q<<M>>
P<<Q>> Q<<P>>
R-Node S-Node T-Node U-Node
P<<R>> P<<S>> Q<<T>> Q<<U>>
Fig 4An example X.509 Certificate Hierarchy
Certificates may be revoked before their expiry by the issuing CA on the following
grounds:
(i) Compromise of private key of a user has been identified.
(ii) The CA no more certifies the user
(iii) CA certificate itself is compromised
For all such revoked certificates, CA maintains a list termed as Certificate Revocation
List (CRL)
Such lists are maintained CA wise in the directory.
Each CRL contains (Figure 2 (b)) name of issuer, list creation time, next scheduled date
for posting CRL and revoked certificate details (as in this list entry).
The revoked certificate details include certificate serial number and revocation date.
Thus, a user trying to obtain a user’s certificate, first looks it into CRLs in the directory
for identifying whether it is valid or revoked. The user may also maintain certificates
and CRLs into cache for decreasing the search and access time.
Authentication procedures
X.509 authentication procedures utilize digital signatures.
For creating digital signature each party obtains public key of other from the certificate.
The certificates are shared either via initial messages or via shared directory.
Three authentication procedures exist in X.509 standard; either of these may be used
depending upon requirements.
These authentication procedures are termed as one way, two way and three way
authentication (Figure 5).
One way authentication involves only one message (from sender to receiver). This
message ensures:
(i) Message generation was done by sender only.
(ii) Message is intended for receiver.
(iii) Message is not a replay of previous message and its contents are unforgeable.
This message proves sender identity at the receiver. It has following elements.
(i) Timestamp (tS): generation time and expiration time of message; used for
preventing delivery of old messages.
(ii) Nonce (rS): a unique random value (can be stored at receiver during a particular
message expiration period) used to prevent replay attacks.
(iii) Receiver Identity (IDR): Indicates that message is intended for R
(iv) SigS: digital signature of S, ensuring integrity of message and authenticity of
sender.
(v) Encrypted session key (KSR): message may also be used to transfer the shared
secret session key (KSR) to R after encrypting using public key of R (P R)
Two way authentication has same message from sender to receiver and in addition has
reply message containing the nonce received from sender (rS), timestamp & nonce
generated by R, signature of R and encrypted session key. Thus, in two way
authentication R is also authenticated at S using reply and hence both S&R are able to
verify each others identify.
Three way authentication involves a third message (in addition to first and second
message) that is send by S to R and contains signed copy of nonce r R. This ensures echo
of receiver nonce back to R and proves useful under replay attacks on R.
Sender S Receiver R
1. [tS, rS, IDR, sgnS, EPR (K SR )]
(a) One-way authentication
1. [tS, rS, IDR, sgnS, EPR (K SR )]
2. [tR, rR, IDS,rS, sgnR, EPS (K RS )]
(b) Two-way authentication
1. [tS, rS, IDR, sgnS, EPS (K SR )]
2. [tR, rR, IDS,rS, sgnR, EPS (K RS )]
3. [rR]
(c) Three-way authentication
Fig 5 X.509 Authentication Procedures
