Subkey: The Client's Choice For An Encryption Key To Be Used To Protect This Specific
Subkey: The Client's Choice For An Encryption Key To Be Used To Protect This Specific
Subkey: The Client's Choice For An Encryption Key To Be Used To Protect This Specific
TGS.
Finally, for the client/server authentication exchange, several new features appear in version 5. In
message (5), the client may request as an option that mutual authentication is required. The
authenticator includes several new fields as follows:
Subkey: The client's choice for an encryption key to be used to protect this specific
application session. If this field is omitted, the session key from the ticket (Kc,v) is used.
Sequence number: An optional field that specifies the starting sequence number
to be use may be sequence numbered to detect replays.
If mutual authentication is required, the server responds with message (6). This message includes
the timestamp from the authenticator. Note that in version 4, the timestamp was incremented by
one. This is not necessary in version 5 because the nature of the format of messages is such that it is
not possible for an opponent to create message (6) without knowledge of the appropriate encryption
keys.
Ticket Flags
The flags field included in tickets in version 5 supports expanded functionality compared to that
available in version 4.
X.509 Certificates
Overview:
– version (1, 2, or 3)
X.509 defines a framework for the provision of authentication services by the X.500 directory to its
users. The directory may serve as a repository of public-key certificates. Each certificate contains
the public key of a user and is signed with the private key of a trusted certification authority. In
addition, X.509 defines alternative authentication protocols based on the use of public-key
certificates.
X.509 is an important standard because the certificate structure and authentication protocols defined
in X.509 are used in a variety of contexts. For example, the X.509 certificate format is used in
S/MIME), IP Security and SSL/TLS and SET
X.509 is based on the use of public-key cryptography and digital signatures. The standard does not
dictate the use of a specific algorithm but recommends RSA. The digital signature scheme is
assumed to require the use of a hash function.
Certificates
The heart of the X.509 scheme is the public-key certificate associated with each user. These user
certificates are assumed to be created by some trusted certification authority (CA) and placed in the
directory by the CA or by the user.
Version:
Differentiates among successive versions of the certificate format; the default is version 1. If the
Issuer Unique Identifier or Subject Unique Identifier are present, the value must be version 2. If one
or more extensions are present, the version must be version 3.
Serial number:
An integer value, unique within the issuing CA, that is unambiguously associated with this
certificate.
Signature algorithm identifier:
The algorithm used to sign the certificate, together with any associated parameters. Because this
information is repeated in the Signature field at the end of the certificate, this field has little, if any,
utility.
Issuer name:
X.500 name of the CA that created and signed this certificate.
Period of validity:
Consists of two dates: the first and last on which the certificate is valid.
Subject name:
The name of the user to whom this certificate refers. That is, this certificate certifies the public key
of the subject who holds the corresponding private key.
Subject's public-key information:
The public key of the subject, plus an identifier of the algorithm for which this key is to be used,
together with any associated parameters.
Issuer unique identifier:
An optional bit string field used to identify uniquely the issuing CA in the event the
X.500 name has been reused for different entities.
Subject unique identifier:
An optional bit string field used to identify uniquely the subject in the event the
X.500 name has been reused for different entities.
Extensions:
A set of one or more extension fields. Extensions were added in version 3 and are discussed later in
this section.
Signature:
Covers all of the other fields of the certificate; it contains the hash code of the other fields,
encrypted with the CA's private key. This field includes the signature algorithm identifie
The standard uses the following notation to define a certificate: CA<<A>> = CA {V, SN, AI, CA,
TA, A, Ap} where
Y <<X>> = the certificate of user X issued by certification authority Y Y {I} = the signing of
I by Y. It consists of I with an encrypted hash code appended
The CA signs the certificate with its private key. If the corresponding public key is known to a user,
then that user can verify that a certificate signed by the CA is valid.
Any user with access to the public key of the CA can verify the user public key that was
certified.
No party other than the certification authority can modify the certificate without this
being detected.
ecause certificates are unforgeable, they can be placed in a directory without the need for the
directory to make special efforts to protect them.
If all users subscribe to the same CA, then there is a common trust of that CA. All user certificates
can be placed in the directory for access by all users.
If there is a large community of users, it may not be practical for all users to subscribe to the same
CA. Because it is the CA that signs certificates, each participating user must have a copy of the
CA's own public key to verify signatures. This public key must be provided to each user in an
absolutely secure (with respect to integrity and authenticity) way so that the user has confidence in
the associated certificates. Thus, with many users, it may be more practical for there to be a
number of CAs, each of which securely provides its public key to some fraction of the users.
Now suppose that A has obtained a certificate from certification authority X1 and B has obtained a
certificate from CA X2. If A does not securely know the public key of X2, then B's certificate,
issued by X2, is useless to A.
A can read B's certificate, but A cannot verify the signature. However, if the two CAs have
securely exchanged their own public keys, the following procedure will enable A to obtain B's
public key:
1. A obtains, from the directory, the certificate of X2 signed by X1. Because A securely
knows X1's public key, A can obtain X2 's public key from its certificate and verify it by means of
X1's signature on the certificate.
2. A then goes back to the directory and obtains the certificate of B signed by X2
Because A now has a trusted copy of X2's public key, A can verify the signature
and securely obtain B's public key.
A has used a chain of certificates to obtain B's public key. In the notation of X.509, this chain is
expressed as
X1<<X2>> X2 <<B>>
In the same fashion, B can obtain A's public key with the reverse chain: X2<<X1>> X1 <<A>>
This scheme need not be limited to a chain of two certificates. An arbitrarily long path of
CAs can be followed to produce a chain. A chain with N elements would be expressed as
All these certificates of CAs by CAs need to appear in the directory, and the user needs to know
how they are linked to follow a path to another user's public-key certificate. X.509 suggests that
CAs be arranged in a hierarchy so that navigation is straightforward.
Figure 14.5, taken from X.509, is an example of such a hierarchy. The connected circles indicate
the hierarchical relationship among the CAs; the associated boxes indicate certificates maintained
in the directory for each CA entry. The directory entry for each CA includes two types of
certificates:
CA Hierarchy Use
In the example given below , user A can acquire the following certificates from the directory to
establish a certification path to B:
When A has obtained these certificates, it can unwrap the certification path in sequence to recover a
trusted copy of B's public key. Using this public key, A can send encrypted
Messages to B. If A wishes to receive encrypted messages back from B, or to sign messages sent to
B, then B will require A's public key, which can be obtained from the following certification path:
B can obtain this set of certificates from the directory, or A can provide them as part of its initial
message to B.
Certificate Revocation
• Certificates have a period of validity
• may need to revoke before expiry, for the following reasons eg:
1. user's private key is compromised
2. User is no longer certified by this CA
Authentication Procedures
X.509 includes three alternative authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures
One-Way Authentication
• 1 message ( A->B) used to establish
– the identity of A and that message is from A
– message was intended for B
– integrity & originality of message
• message must include timestamp, nonce, B's identity and is signed by A
Two-Way Authentication
• 2 messages (A->B, B->A) which also establishes in addition:
– the identity of B and that reply is from B
– that reply is intended for A
– integrity & originality of reply
reply includes original nonce from A, also timestamp and nonce from B
Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables above authentication without
synchronized clocks
• has reply from a back to B containing signed copy of nonce from B
• means that timestamps need not be checked or relied upon
X.509 Version 3
The X.509 version 2 format does not convey all of the information that recent design and
implementation experience has shown to be needed. [FORD95] lists the following requirements not
satisfied by version 2:
1. The Subject field is inadequate to convey the identity of a key owner to a public- key user.
2. The Subject field is also inadequate for many applications, which typically recognize entities by
an Internet e-mail address, a URL, or some other Internet- related identification.
3. There is a need to indicate security policy information. There is a need to limit the damage that
can result from a faulty or malicious CA by setting constraints on the applicability of a particular
certificate.
4. It is important to be able to identify different keys used by the same owner at different
times.
The certificate extensions fall into three main categories: key and policy information, subject and
issuer attributes, and certification path constraints.