W4-NS
akhilesh7593
CH04NetSec6e_accessiblePPT.pptxNetwork Security Essentials: Applications and Standards
Sixth Edition
Chapter 4
Key Distribution and User Authentication
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
If this PowerPoint presentation contains mathematical equations, you may need to check that your computer has the following installed:
1) MathType Plugin
2) Math Player (free versions available)
3) NVDA Reader (free versions available)
This chapter provides a general overview of the subject matter that structures the material in the remainder of the book. We begin with a general discussion of network security services and mechanisms and of the types of attacks they are designed for. Then we develop a general overall model within which the security services and mechanisms can be viewed.
Remote User Authentication Principles (1 of 2)
In most computer security contexts, user authentication is the fundamental building block and the primary line of defense
User authentication is the basis for most types of access control and for user accountability
R F C 4949 (Internet Security Glossary) defines user authentication as the process of verifying an identity claimed by or for a system entity
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
In most computer security contexts, user authentication is the fundamental building
block and the primary line of defense. User authentication is the basis for most
types of access control and for user accountability. RFC 4949 (Internet Security
Glossary) defines user authentication as the process of verifying an identity claimed
by or for a system entity. This process consists of two steps:
■ Identification step: Presenting an identifier to the security system. (Identifiers
should be assigned carefully, because authenticated identities are the basis for
other security services, such as access control service.)
■ Verification step: Presenting or generating authentication information that
corroborates the binding between the entity and the identifier.
In essence, identification is the means by which a user provides a claimed identity
to the system; user authentication is the means of establishing the validity of
the claim. Note that user authentication is distinct from message authentication. As
defined in Chapter 3, message authentication is a procedure that allows communicating
parties to verify that the contents of a received message have not been altered and
that the source is authentic. This chapter is concerned solely with user authentication.
2
Remote User Authentication Principles (2 of 2)
Identification step
Presenting an identifier to the security system
Verification step
Presenting or generating authentication information that corroborates the binding between the entity and the identifier
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
In most computer security contexts, user authentication is the fundamental building
block and the primary line of defense. User authentication is the basis for most
types of access control and for user accountability. RFC 4949 (Internet Security
Glossary) defines user authentication as the process of verifying an identity claimed
by or for a system entity. This process consists of two steps:
■ Identification step: Presenting an identifier to the security system. (Identifiers
should be assigned carefully, because authenticated identities are the basis for
other security services, such as access control service.)
■ Verification step: Presenting or generating authentication information that
corroborates the binding between the entity and the identifier.
In essence, identification is the means by which a user provides a claimed identity
to the system; user authentication is the means of establishing the validity of
the claim. Note that user authentication is distinct from message authentication. As
defined in Chapter 3, message authentication is a procedure that allows communicating
parties to verify that the contents of a received message have not been altered and
that the source is authentic. This chapter is concerned solely with user authentication.
3
N I S T Model for Electronic User Authentication
N I S T S P 800-63-2 (Electronic Authentication Guideline, August 2013 defines electronic user authentication as the process of establishing confidence in user identities that are presented electronically to an information system
Systems can use the authenticated identity to determine if the authenticated individual is authorized to perform particular functions
In many cases, the authentication and transaction or other authorized function take place across an open network such as the Internet
Equally, authentication and subsequent authorization can take place locally, such as across a local area network
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
NIST SP 800-63-2 (Electronic Authentication Guideline , August 2013) defines electronic
user authentication as the process of establishing confidence in user identities
that are presented electronically to an information system. Systems can use the authenticated
identity to determine if the authenticated individual is authorized to perform
particular functions, such as database transactions or access to system resources. In
many cases, the authentication and transaction or other authorized function take
place across an open network such as the Internet. Equally, authentication and subsequent
authorization can take place locally, such as across a local area network.
4
Figure 4-1: The N I S T S P 800-63-2 E-Authentication Architectural Model
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
SP 800-63-2 defines a general model for user authentication that involves
a number of entities and procedures. We discuss this model with reference to
Figure 4.1.
The initial requirement for performing user authentication is that the user must
be registered with the system. The following is a typical sequence for registration. An
applicant applies to a registration authority (RA) to become a subscriber of a credential
service provider (CSP). In this model, the RA is a trusted entity that establishes
and vouches for the identity of an applicant to a CSP. The CSP then engages
in an exchange with the subscriber. Depending on the details of the overall authentication
system, the CSP issues some sort of electronic credential to the subscriber.
The credential is a data structure that authoritatively binds an identity and additional
attributes to a token possessed by a subscriber, and can be verified when presented
to the verifier in an authentication transaction. The token could be an encryption
key or an encrypted password that identifies the subscriber. The token may be issued
by the CSP, generated directly by the subscriber, or provided by a third party. The
token and credential may be used in subsequent authentication events.
Once a user is registered as a subscriber, the actual authentication process can
take place between the subscriber and one or more systems that perform authentication
and, subsequently, authorization. The party to be authenticated is called a
claimant and the party verifying that identity is called a verifier. When a claimant
successfully demonstrates possession and control of a token to a verifier through an
authentication protocol, the verifier can verify that the claimant is the subscriber
named in the corresponding credential. The verifier passes on an assertion about the
identity of the subscriber to the relying party (RP). That assertion includes identity
information about a subscriber, such as the subscriber name, an identifier assigned
at registration, or other subscriber attributes that were verified in the registration
process. The RP can use the authenticated information provided by the verifier to
make access control or authorization decisions.
An implemented system for authentication will differ from or be more complex
than this simplified model, but the model illustrates the key roles and functions
needed for a secure authentication system.
5
Means of Authentication (1 of 2)
There are four general means of authenticating a user’s identity, which can be used alone or in combination
Something the individual knows
Examples include a password, a personal identification number (P I N), or answers to a prearranged set of questions
Something the individual possesses
Examples include cryptographic keys, electronic keycards, smart cards, and physical keys
This type of authenticator is referred to as a token
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
There are four general means of authenticating a user’s identity, which can be used
alone or in combination:
■ Something the individual knows: Examples include a password, a personal
identification number (PIN), or answers to a prearranged set of questions.
■ Something the individual possesses: Examples include cryptographic keys,
electronic keycards, smart cards, and physical keys. This type of authenticator
is referred to as a token .
■ Something the individual is (static biometrics): Examples include recognition
by fingerprint, retina, and face.
■ Something the individual does (dynamic biometrics): Examples include
recognition by voice pattern, handwriting characteristics, and typing rhythm.
All of these methods, properly implemented and used, can provide secure
user authentication. However, each method has problems. An adversary may be
able to guess or steal a password. Similarly, an adversary may be able to forge or
steal a token. A user may forget a password or lose a token. Furthermore, there
is a significant administrative overhead for managing password and token information
on systems and securing such information on systems. With respect to biometric
authenticators, there are a variety of problems, including dealing with false
positives and false negatives, user acceptance, cost, and convenience. For network-based
user authentication, the most important methods involve cryptographic keys
and something the individual knows, such as a password.
6
Means of Authentication (2 of 2)
Something the individual is (static biometrics)
Examples include recognition by fingerprint, retina, and face
Something the individual does (dynamic biometrics)
Examples include recognition by voice pattern, handwriting characteristics, and typing rhythm
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
There are four general means of authenticating a user’s identity, which can be used
alone or in combination:
■ Something the individual knows: Examples include a password, a personal
identification number (PIN), or answers to a prearranged set of questions.
■ Something the individual possesses: Examples include cryptographic keys,
electronic keycards, smart cards, and physical keys. This type of authenticator
is referred to as a token .
■ Something the individual is (static biometrics): Examples include recognition
by fingerprint, retina, and face.
■ Something the individual does (dynamic biometrics): Examples include
recognition by voice pattern, handwriting characteristics, and typing rhythm.
All of these methods, properly implemented and used, can provide secure
user authentication. However, each method has problems. An adversary may be
able to guess or steal a password. Similarly, an adversary may be able to forge or
steal a token. A user may forget a password or lose a token. Furthermore, there
is a significant administrative overhead for managing password and token information
on systems and securing such information on systems. With respect to biometric
authenticators, there are a variety of problems, including dealing with false
positives and false negatives, user acceptance, cost, and convenience. For network-based
user authentication, the most important methods involve cryptographic keys
and something the individual knows, such as a password.
7
Symmetric Key Distribution using Symmetric Encryption
For symmetric encryption to work, the two parties to an exchange must share the same key, and that key must be protected from access by others
Frequent key changes are usually desirable to limit the amount of data compromised if an attacker learns the key
Key distribution technique
The means of delivering a key to two parties that wish to exchange data, without allowing others to see the key
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
8
For symmetric encryption to work, the two parties to an exchange must share
the same key, and that key must be protected from access by others. Furthermore,
frequent key changes are usually desirable to limit the amount of data compromised
if an attacker learns the key. Therefore, the strength of any cryptographic
system rests with the “key distribution technique,” a term that refers to the means of
delivering a key to two parties that wish to exchange data, without allowing others
to see the key.
Key Distribution
For two parties A and B, there are the following options:
A key can be selected by A and physically delivered to B
A third party can select the key and physically deliver it to A and B
If A and B have previously and recently used a key, one party could transmit the new key to the other, using the old key to encrypt the new key
If A and B each have an encrypted connection to a third party C, C could deliver a key on the encrypted links to A and B
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Key distribution can be achieved in a number of ways. For two
parties A and B, there are the following options:
1. A key could be selected by A and physically delivered to B.
2. A third party could select the key and physically deliver it to A and B.
3. If A and B have previously and recently used a key, one party could transmit
the new key to the other, using the old key to encrypt the new key.
4. If A and B each have an encrypted connection to a third party C, C could
deliver a key on the encrypted links to A and B.
Options 1 and 2 call for manual delivery of a key. For link encryption, this is
a reasonable requirement, because each link encryption device is only going to be
exchanging data with its partner on the other end of the link. However, for end-to-end
encryption over a network, manual delivery is awkward. In a distributed system,
any given host or terminal may need to engage in exchanges with many other
hosts and terminals over time. Thus, each device needs a number of keys supplied
dynamically. The problem is especially difficult in a wide-area distributed system.
Option 3 is a possibility for either link encryption or end-to-end encryption,
but if an attacker ever succeeds in gaining access to one key, then all subsequent
keys are revealed. Even if frequent changes are made to the link encryption keys,
these should be done manually. To provide keys for end-to-end encryption, option
4 is preferable.
For option 4 , two kinds of keys are used:
• Session key: When two end systems (hosts,
terminals, etc.) wish to communicate,
they establish a logical connection (e.g., virtual circuit). For the duration
of that logical connection, called a session, all user data are encrypted with
a one-time session key. At the conclusion of the session the session key is
destroyed.
• Permanent key: A permanent key is a key used between entities for the purpose
of distributing session keys.
A necessary element of option 4 is a key distribution center (KDC) . The KDC
determines which systems are allowed to communicate with each other. When permission
is granted for two systems to establish a connection, the key distribution
center provides a one-time session key for that connection.
In general terms, the operation of a KDC proceeds as follows:
1. When host A wishes to set up a connection to host B, it transmits a connection request
packet to the KDC. The communication between A and the KDC is
encrypted using a master key shared only by A and the KDC.
2. If the KDC approves the connection request, it generates a unique one-time
session key. It encrypts the session key using the permanent key it shares with
A and delivers the encrypted session key to A. Similarly, it encrypts the session
key using the permanent key it shares with B and delivers the encrypted session
key to B.
3. A and B can now set up a logical connection and exchange messages and data,
all encrypted using the temporary session key.
The automated key distribution approach provides the flexibility and dynamic
characteristics needed to allow a number of users to access a number of servers and
for the servers to exchange data with each other. The most widely used application
that implements this approach is Kerberos, described in the next section.
9
Kerberos (1 of 2)
Key distribution and user authentication service developed at M I T
Provides a centralized authentication server whose function is to authenticate users to servers and servers to users
Relies exclusively on symmetric encryption, making no use of public-key encryption
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Kerberos is a key distribution and user authentication service developed at MIT.
The problem that Kerberos addresses is this: Assume an open distributed environment
in which users at workstations wish to access services on servers distributed
throughout the network. We would like for servers to be able to restrict access to
authorized users and to be able to authenticate requests for service. In this environment,
a workstation cannot be trusted to identify its users correctly to network
services. In particular, the following three threats exist:
1. A user may gain access to a particular workstation and pretend to be another
user operating from that workstation.
2. A user may alter the network address of a workstation so that the requests
sent from the altered workstation appear to come from the impersonated
workstation.
3. A user may eavesdrop on exchanges and use a replay attack to gain entrance
to a server or to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to services
and data that he or she is not authorized to access. Rather than building elaborate
authentication protocols at each server, Kerberos provides a centralized authentication
server whose function is to authenticate users to servers and servers to users.
Kerberos relies exclusively on symmetric encryption, making no use of public-key
encryption.
Two versions of Kerberos are in use. Version 4 [MILL88, STEI88] implementations
still exist, although this version is being phased out. Version 5 [KOHL94]
corrects some of the security deficiencies of version 4 and has been issued as a proposed
Internet Standard (RFC 4120).
Because of the complexity of Kerberos, it is best to start with a description
of version 4. This enables us to see the essence of the Kerberos strategy without
considering some of the details required to handle subtle security threats. Then, we
examine version 5.
10
Kerberos (2 of 2)
Two versions are in use
Version 4 implementations still exist, although this version is being phased out
Version 5 corrects some of the security deficiencies of version 4 and has been issued as a proposed Internet Standard (R F C 4120)
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Kerberos is a key distribution and user authentication service developed at MIT.
The problem that Kerberos addresses is this: Assume an open distributed environment
in which users at workstations wish to access services on servers distributed
throughout the network. We would like for servers to be able to restrict access to
authorized users and to be able to authenticate requests for service. In this environment,
a workstation cannot be trusted to identify its users correctly to network
services. In particular, the following three threats exist:
1. A user may gain access to a particular workstation and pretend to be another
user operating from that workstation.
2. A user may alter the network address of a workstation so that the requests
sent from the altered workstation appear to come from the impersonated
workstation.
3. A user may eavesdrop on exchanges and use a replay attack to gain entrance
to a server or to disrupt operations.
In any of these cases, an unauthorized user may be able to gain access to services
and data that he or she is not authorized to access. Rather than building elaborate
authentication protocols at each server, Kerberos provides a centralized authentication
server whose function is to authenticate users to servers and servers to users.
Kerberos relies exclusively on symmetric encryption, making no use of public-key
encryption.
Two versions of Kerberos are in use. Version 4 [MILL88, STEI88] implementations
still exist, although this version is being phased out. Version 5 [KOHL94]
corrects some of the security deficiencies of version 4 and has been issued as a proposed
Internet Standard (RFC 4120).
Because of the complexity of Kerberos, it is best to start with a description
of version 4. This enables us to see the essence of the Kerberos strategy without
considering some of the details required to handle subtle security threats. Then, we
examine version 5.
11
Kerberos Version 4
A basic third-party authentication scheme
Authentication Server (A S)
Users initially negotiate with A S to identify self
A S provides a non-corruptible authentication credential (ticket granting ticket T G T)
Ticket Granting Server (T G S)
Users subsequently request access to other services from T G S on basis of users T G T
Complex protocol using D E S
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
12
Version 4 of Kerberos makes use of DES, in a rather elaborate protocol, to provide
the authentication service. Viewing the protocol as a whole, it is difficult to see the
need for the many elements contained therein. Therefore, we adopt a strategy used
by Bill Bryant [BRYA88] and build up to the full protocol by looking first at several
hypothetical dialogues. Each successive dialogue adds additional complexity to
counter security vulnerabilities revealed in the preceding dialogue.
In an unprotected network environment,
any client can apply to any server for service. The obvious security risk is that of
impersonation. An opponent can pretend to be another client and obtain unauthorized
privileges on server machines. To counter this threat, servers must be able to
confirm the identities of clients who request service. Each server can be required to
undertake this task for each client/server interaction, but in an open environment,
this places a substantial burden on each server.
An alternative is to use an authentication server (AS) that knows the passwords
of all users and stores these in a centralized database. In addition, the AS
shares a unique secret key with each server. These keys have been distributed
physically or in some other secure manner.
Although the foregoing scenario solves
some of the problems of authentication in an open network environment, problems
remain. Two in particular stand out. First, we would like to minimize the number
of times that a user has to enter a password. Suppose each ticket can be used only
once. If user C logs on to a workstation in the morning and wishes to check his or her
mail at a mail server, C must supply a password to get a ticket for the mail server.
If C wishes to check the mail several times during the day, each attempt requires
reentering the password. We can improve matters by saying that tickets are reusable.
For a single logon session, the workstation can store the mail-server ticket after it is
received and use it on behalf of the user for multiple accesses to the mail server.
However, under this scheme, it remains the case that a user would need a new
ticket for every different service. If a user wished to access a print server, a mail
server, a file server, and so on, the first instance of each access would require a new
ticket and hence require the user to enter the password.
The second problem is that the earlier scenario involved a plaintext transmission
of the password [message (1)]. An eavesdropper could capture the password
and use any service accessible to the victim.
To solve these additional problems, we introduce a scheme for avoiding plaintext
passwords and a new server, known as the ticket-granting server (TGS) .
The new service, TGS, issues tickets to users who have been authenticated to
AS. Each time the user requires
access to a new service, the client applies to the TGS, using the ticket to authenticate
itself. The TGS then grants a ticket for the particular service. The client saves
each service-granting ticket and uses it to authenticate its user to a server each time
a particular service is requested.
Table 4-1: Summary of Kerberos Version 4 Message Exchanges
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4.1, shows the actual Kerberos protocol.
Table 4.1a shows the technique for distributing the session key.
13
Figure 4-2: Overview of Kerberos
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 4.2 provides simplified overview.
14
Figure 4-3: Kerberos Exchanges
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 4.2 illustrates the Kerberos exchanges among the parties.
15
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (1 of 7)
(a) Authentication Service Exchange
| Message (1) | Client requests ticket-granting ticket. |
| I D sub c | Tells A S identity of user from this client. |
| I D sub t g s | Tells A S that user requests access to T G S. |
| T S sub 1 | Allows A S to verify that client's clock is synchronized with that of A S. |
| Message (2) | A S returns ticket-granting ticket. |
| K sub c | Encryption is based on user's password. enabling A S and client to verify password. and protecting contents of message (2). |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4.2 summarizes the justification for each of the elements in the Kerberos protocol.
16
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (2 of 7)
| K sub c t g s | Copy of session key accessible to client created by A S to permit secure exchange between client and T G S without requiring them to share a permanent key. |
| I D sub t g s | Confirms that this ticket is for the T G S. |
| T S sub 2 | Informs client of time this ticket was issued. |
| Lifetime sub 2 | Informs client of the lifetime of this ticket. |
| Ticket sub t g s | Ticket to be used by client to access T G S. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (3 of 7)
(b) Ticket-Granting Service Exchange
| Message (3) | Client requests service-granting ticket. |
| I D sub v | Tells T G S that user requests access to server V. |
| Ticket sub t g s | Assures T G S that this user has been authenticated by A S. |
| Authenticator sub c | Generated by client to validate ticket . |
| Message (4) | T G S returns service-granting ticket. |
| K sub c t g s | Key shared only by C and T G S protects contents of message(4) |
| K sub c comma v | Copy or session key ‘accessible to client created by T G S to permit secure exchange between client and server Without requiring them to share a permanent key. |
| I D sub v | Confirms that this ticket is for server V. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (4 of 7)
| T S sub 4 | Informs client of time this ticket was issued. |
| Ticket sub v | Ticket to be used by client to access server V. |
| Ticket sub t g s | Reusable so that user does not have to reenter password. |
| K sub t g s | Ticket is encrypted with key known only to A S and T G S, to prevent Tampering. |
| K sub c t g s | Copy or session key accessible to T G S used to decrypt authenticator, thereby authenticating ticket. |
| I D sub c | Indicates the rightful owner or this ticket. |
| A D sub c | Prevents use of ticket from workstation other than one that initially requested the ticket. |
| I D sub t g s | Assures server that it has decrypted ticket properly. |
| T S sub 2 | Informs T G S or time this ticket was issued. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (5 of 7)
| Lifetime sub 2 | Prevents replay after ticket has expired. |
| Authenticator sub c | Assures T G S that the ticket presenter is the same as the client for whom the ticket Was issued has very short lifetime to prevent replay. |
| K sub c t g s | Authenticator is encrypted with key known only to client and T G S to prevent tampering. |
| I D sub c | Must match I D in ticket to authenticate ticket. |
| A D sub c | Must match address in ticket to authenticate ticket |
| T S sub 3 | Informs T G S or time this authenticator was generated. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (6 of 7)
(c) Client/Server Authentication
| Message (5) | Client requests service. |
| Ticket sub v | Assures server that this user has been authenticated by A S. |
| Authenticator sub c | Generated by client to validate ticket. |
| Message (6) | Optional authentication of server to client. |
| K sub c, v | Assures C that this message is from V. |
| T S sub 5 plus 1 | Assures C that this is not a replay of an old reply. |
| Ticket sub v | Reusable so that client does not need to request a new ticket from T G S for each access to the same server. |
| K sub v | Ticket is encrypted with key known only to T G S and server to prevent Tampering. |
| K sub c, v | Copy of session key accessible to client: used to decrypt authenticator thereby authenticating ticket. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4-2 Rationale for the Elements of the Kerberos Version 4 Protocol (7 of 7)
| I D sub c | Indicates the rightful owner of this ticket. |
| A D sub c | prevents use of ticket from workstation other than one that initially requested the ticket. |
| I D sub v | Assures server that it has decrypted ticket properly. |
| T S sub 4 | Informs server of time this ticket was issued. |
| Lifetime sub 4 | Prevents replay after ticket has expired. |
| Authenticator sub c | Assures server that the ticket presenter is the same as the client for whom the ticket was issued: has very short lifetime to prevent replay. |
| K sub c, v | Authenticator is encrypted with key known only to client and server to prevent tampering. |
| I D sub c | Must match I D in ticket to authenticate ticket. |
| A D sub c | Must match address in ticket to authenticate ticket. |
| T S sub 5 | Informs server of time this authenticator was generated. |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
22
Kerberos Realms (1 of 2)
A set of managed nodes that share the same Kerberos database
The Kerberos database resides on the Kerberos master computer system, which should be kept in a physically secure room
A read-only copy of the Kerberos database might also reside on other Kerberos computer systems
All changes to the database must be made on the master computer system
Changing or accessing the contents of a Kerberos database requires the Kerberos master password
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A full-service Kerberos environment
consisting of a Kerberos server, a number of clients, and a number of application
servers requires the following:
1. The Kerberos server must have the user ID and hashed passwords of all participating
users in its database. All users are registered with the Kerberos
server.
2. The Kerberos server must share a secret key with each server. All servers are
registered with the Kerberos server.
Such an environment is referred to as a Kerberos realm . The concept of realm
can be explained as follows. A Kerberos realm is a set of managed nodes that share
the same Kerberos database. The Kerberos database resides on the Kerberos master
computer system, which should be kept in a physically secure room. A read-only
copy of the Kerberos database might also reside on other Kerberos computer systems.
However, all changes to the database must be made on the master computer
system. Changing or accessing the contents of a Kerberos database requires the
Kerberos master password.
23
Kerberos Realms (2 of 2)
A Kerberos environment consists of:
A Kerberos server
A number of clients
A number of application servers
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A full-service Kerberos environment
consisting of a Kerberos server, a number of clients, and a number of application
servers requires the following:
1. The Kerberos server must have the user ID and hashed passwords of all participating
users in its database. All users are registered with the Kerberos
server.
2. The Kerberos server must share a secret key with each server. All servers are
registered with the Kerberos server.
Such an environment is referred to as a Kerberos realm . The concept of realm
can be explained as follows. A Kerberos realm is a set of managed nodes that share
the same Kerberos database. The Kerberos database resides on the Kerberos master
computer system, which should be kept in a physically secure room. A read-only
copy of the Kerberos database might also reside on other Kerberos computer systems.
However, all changes to the database must be made on the master computer
system. Changing or accessing the contents of a Kerberos database requires the
Kerberos master password.
24
Kerberos Principal
A service or user that is known to the Kerberos system
Each Kerberos principal is identified by its principal name
Principal names consist of three parts
A service or user name + An instance name + A realm name = Principal name
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
A related concept is that of a Kerberos principal, which
is a service or user that is known to the Kerberos system. Each Kerberos principal is
identified by its principal name. Principal names consist of three parts: a service or
user name, an instance name, and a realm name.
Networks of clients and servers under different administrative organizations
typically constitute different realms. That is, it generally is not practical or does not
conform to administrative policy to have users and servers in one administrative
domain registered with a Kerberos server elsewhere. However, users in one realm
may need access to servers in other realms, and some servers may be willing to provide
service to users from other realms, provided that those users are authenticated.
25
Differences between Versions 4 and 5
| Environmental Shortcomings Encryption system dependence Internet protocol dependence Message byte ordering Ticket lifetime Authentication forwarding Interrealm authentication | Technical Deficiencies Double encryption P C B C encryption Session keys Password attacks |
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Version 5 is intended to address the
limitations of version 4 in two areas: environmental shortcomings and technical
deficiencies. We briefly summarize the improvements in each area. Kerberos version
4 did not fully address the need to be of general purpose. This led to the following
environmental shortcomings
Encryption system dependence
Internet protocol dependence
Message byte ordering
Ticket lifetime
Authentication forwarding
Interrealm authentication
Apart from these environmental limitations, there are technical deficiencies
in the version 4 protocol itself. Most of these deficiencies were documented in
[BELL90], and version 5 attempts to address these. The deficiencies are the
Following:
Double encryption
PCBC encryption
Session keys
Password attacks
26
Table 4-3: Summary of Kerberos Version 5 Message Exchanges
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Table 4.3 summarizes the basic version
5 dialogue. This is best explained by comparison with version 4 (Table 4.1).
First, consider the authentication service exchange . Message (1) is a client
request for a ticket-granting ticket. As before, it includes the ID of the user and the
TGS. The following new elements are added:
■ Realm: Indicates realm of user.
■ Options: Used to request that certain flags be set in the returned ticket.
■ Times: Used by the client to request the following time settings in the ticket:
from: the desired start time for the requested ticket
till: the requested expiration time for the requested ticket
rtime: requested renew-till time
■ Nonce: A random value to be repeated in message (2) to assure that the
response is fresh and has not been replayed by an opponent.
Message (2) returns a ticket-granting ticket, identifying information for the
client, and a block encrypted using the encryption key based on the user’s password.
This block includes the session key to be used between the client and the TGS, times
specified in message (1), the nonce from message (1), and TGS identifying information.
The ticket itself includes the session key, identifying information for the client,
the requested time values, and flags that reflect the status of this ticket and the
requested options. These flags introduce significant new functionality to version 5.
For now, we defer a discussion of these flags and concentrate on the overall structure
of the version 5 protocol.
Let us now compare the ticket-granting service exchange for versions 4 and 5.
We see that message (3) for both versions includes an authenticator, a ticket, and
the name of the requested service. In addition, version 5 includes requested times
and options for the ticket and a nonce—all with functions similar to those of message
(1). The authenticator itself is essentially the same as the one used in version 4.
Message (4) has the same structure as message (2). It returns a ticket plus
information needed by the client, with the information encrypted using the session
key now shared by the client and the 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.
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. The
subkey field, if present, overrides the subkey field, if present, in message (5). The
optional sequence number field specifies the starting sequence number to be used
by the client.
27
Key Distribution using Asymmetric Encryption (1 of 2)
One of the major roles of public-key encryption is to address the problem of key distribution
There are two distinct aspects to the use of public-key encryption in this regard:
The distribution of public keys
The use of public-key encryption to distribute secret keys
Public-key certificate
Consists of a public key plus a user I D of the key owner, with the whole block signed by a trusted third party
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
One of the major roles of public-key encryption is to address the problem of key
distribution. There are actually two distinct aspects to the use of public-key encryption
in this regard.
• The distribution of public keys.
• The use of public-key encryption to distribute secret keys.
On the face of it, the point of public-key encryption is that the public key is public.
Thus, if there is some broadly accepted public-key algorithm, such as RSA, any
participant can send his or her public key to any other participant or broadcast the
key to the community at large. Although this approach is convenient, it has a major
weakness. Anyone can forge such a public announcement. That is, some user could
pretend to be user A and send a public key to another participant or broadcast such
a public key. Until such time as user A discovers the forgery and alerts other participants,
the forger is able to read all encrypted messages intended for A and can use
the forged keys for authentication.
The solution to this problem is the public-key certificate . In essence, a certificate
consists of a public key plus a user ID of the key owner, with the whole block
signed by a trusted third party. Typically, the third party is a certificate authority
(CA) that is trusted by the user community, such as a government agency or a financial
institution. A user can present his or her public key to the authority in a secure
manner and obtain a certificate. The user can then publish the certificate. Anyone
needing this user’s public key can obtain the certificate and verify that it is valid by
way of the attached trusted signature. Figure 4.3 illustrates the process.
One scheme has become universally accepted for formatting public-key certificates:
the X.509 standard. X.509 certificates are used in most network security
applications, including IP security, secure sockets layer (SSL), and S/MIME—all of
which are discussed in subsequent chapters. X.509 is examined in detail in the next
section.
28
Key Distribution using Asymmetric Encryption (2 of 2)
Typically, the third party is a certificate authority (C A) that is trusted by the user community, such as a government agency or a financial institution
A user can present his or her public key to the authority in a secure manner and obtain a certificate
The user can then publish the certificate
Anyone needing this user’s public key can obtain the certificate and verify that it is valid by way of the attached trusted signature
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
One of the major roles of public-key encryption is to address the problem of key
distribution. There are actually two distinct aspects to the use of public-key encryption
in this regard.
• The distribution of public keys.
• The use of public-key encryption to distribute secret keys.
On the face of it, the point of public-key encryption is that the public key is public.
Thus, if there is some broadly accepted public-key algorithm, such as RSA, any
participant can send his or her public key to any other participant or broadcast the
key to the community at large. Although this approach is convenient, it has a major
weakness. Anyone can forge such a public announcement. That is, some user could
pretend to be user A and send a public key to another participant or broadcast such
a public key. Until such time as user A discovers the forgery and alerts other participants,
the forger is able to read all encrypted messages intended for A and can use
the forged keys for authentication.
The solution to this problem is the public-key certificate . In essence, a certificate
consists of a public key plus a user ID of the key owner, with the whole block
signed by a trusted third party. Typically, the third party is a certificate authority
(CA) that is trusted by the user community, such as a government agency or a financial
institution. A user can present his or her public key to the authority in a secure
manner and obtain a certificate. The user can then publish the certificate. Anyone
needing this user’s public key can obtain the certificate and verify that it is valid by
way of the attached trusted signature. Figure 4.3 illustrates the process.
One scheme has become universally accepted for formatting public-key certificates:
the X.509 standard. X.509 certificates are used in most network security
applications, including IP security, secure sockets layer (SSL), and S/MIME—all of
which are discussed in subsequent chapters. X.509 is examined in detail in the next
section.
29
Figure 4-4: Public-Key Certificate Use
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 4.4 illustrates the generation of a public-key certificate.
30
X.509 Certificates
I T U-T recommendation X.509 is part of the X.500 series of recommendations that define a directory service
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
Defines alternative authentication protocols based on the use of public-key certificates
Was initially issued in 1988
Based on the use of public-key cryptography and digital signatures
The standard does not dictate the use of a specific algorithm but recommends R S A
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
31
ITU-T recommendation X.509 is part of the X.500 series of recommendations that
define a directory service. The directory is, in effect, a server or distributed set
of servers that maintains a database of information about users. The information
includes a mapping from user name to network address, as well as other attributes
and information about the users.
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 (Chapter 8), IP Security (Chapter 9),
and SSL/TLS (Chapter 6).
X.509 was initially issued in 1988. The standard was subsequently revised
in 1993 to address some of the security concerns documented in [IANS90] and
[MITC90]. The standard is currently at version 7, issued in 2012.
Figure 4-5: X.509 Formats
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
X.509 is based on the use of public-key cryptography and digital signatures.
The standard does not dictate the use of a specific digital signature algorithm nor a
specific hash function. Figure 4.5 illustrates the overall X.509 scheme for generation
of a public-key certificate. The certificate for Bob’s public key includes unique identifying
information for Bob, Bob’s public key, and identifying information about
the CA, plus other information as explained subsequently. This information is then
signed by computing a hash value of the information and generating a digital signature
using the hash value and the CA’s private key.
Figure 4.5a shows the general format of a certificate, which includes the following
Elements.
■ 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. Although the X.509 specification is
currently at version 7, no changes have been made to the fields that make up
the certificate since 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. One component of
this field is the digital signature applied to the other fields of the certificate.
This field includes the signature algorithm identifier.
32
Obtaining a User’s Certificate
User certificates generated by a C A have the following characteristics:
Any user with access to the public key of the C A can verify the user public key that was certified
No party other than the certification authority can modify the certificate without this being detected
Because certificates are unforgeable, they can be placed in a directory without the need for the directory to make special efforts to protect them
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
User certificates generated by a CA have the
following characteristics:
• 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.
Because 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. In addition,
a user can transmit his or her certificate directly to other users. In either case,
once B is in possession of A’s certificate, B has confidence that messages it encrypts
with A’s public key will be secure from eavesdropping and that messages signed with
A’s private key are unforgeable.
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 way (with respect
to integrity and authenticity) 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.
33
Figure 4-6: X.509 CA Hierarchy-A Hypothetical Example
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
34
Figure 4.6, taken from X.509, is an example of 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:
• Forward certificates: Certificates of X generated by other CAs
• Reverse certificates: Certificates generated by X that are the certificates of
other CAs
Revocation of Certificates
Each certificate includes a period of validity
Typically a new certificate is issued just before the expiration of the old one
It may be desirable on occasion to revoke a certificate before it expires for one of the following reasons:
The user’s private key is assumed to be compromised
The user is no longer certified by this C A; reasons for this include subject’s name has changed, the certificate is superseded, or the certificate was not issued in conformance with the C A’s policies
The C A’s certificate is assumed to be compromised
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
35
Recall from Figure 4.5 that each certificate includes
a period of validity, much like a credit card. Typically, a new certificate is issued just
before the expiration of the old one. In addition, it may be desirable on occasion to
revoke a certificate before it expires for one of the following reasons.
1. The user’s private key is assumed to be compromised.
2. The user is no longer certified by this CA. Reasons for this include subject’s
name has changed, the certificate is superseded, or the certificate was not
issued in conformance with the CA’s policies.
3. The CA’s certificate is assumed to be compromised.
Each CA must maintain a list consisting of all revoked but not expired certificates
issued by that CA, including both those issued to users and to other CAs.
These lists also should be posted on the directory.
Each certificate revocation list (CRL) posted to the directory is signed by the
issuer and includes (Figure 4.5b) the issuer’s name, the date the list was created, the
date the next CRL is scheduled to be issued, and an entry for each revoked certificate.
Each entry consists of the serial number of a certificate and revocation date for
that certificate. Because serial numbers are unique within a CA, the serial number
is sufficient to identify the certificate.
When a user receives a certificate in a message, the user must determine
whether the certificate has been revoked. The user could check the directory each
time a certificate is received. To avoid the delays (and possible costs) associated
with directory searches, it is likely that the user would maintain a local cache of certificates
and lists of revoked certificates.
X.509 Version 3
Includes a number of optional extensions that may be added to the version 2 format
Each extension consists of:
An extension identifier
A criticality indicator
An extension value
The certificate extensions fall into three main categories:
Key and policy information
Subject and issuer attributes
Certification path constraints
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
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. X.509 names may be relatively short and lacking in obvious
identification details that may be needed by the 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. This enables a security
application or function, such as IPSec, to relate an X.509 certificate to a given
policy.
4. 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.
5. It is important to be able to identify different keys used by the same owner at
different times. This feature supports key life cycle management, in particular
the ability to update key pairs for users and CAs on a regular basis or under
exceptional circumstances.
Rather than continue to add fields to a fixed format, standards developers
felt that a more flexible approach was needed. Thus, version 3 includes a number
of optional extensions that may be added to the version 2 format. Each extension
consists of an extension identifier, a criticality indicator, and an extension value.
The criticality indicator indicates whether an extension can be safely ignored. If
the indicator has a value of TRUE and an implementation does not recognize the
extension, it must treat the certificate as invalid.
The certificate extensions fall into three main categories: key and policy information,
subject and issuer attributes, and certification path constraints.
36
Key and Policy Information
These extensions convey additional information about the subject and issuer keys, plus indicators of certificate policy
A certificate policy is a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements
Includes:
Authority key identifier
Subject key identifier
Key usage
Private-key usage period
Certificate policies
Policy mappings
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
These extensions convey additional information
about the subject and issuer keys, plus indicators of certificate policy. A certificate
policy is a named set of rules that indicates the applicability of a certificate to a
particular community and/or class of application with common security requirements.
For example, a policy might be applicable to the authentication of electronic
data interchange (EDI) transactions for the trading of goods within a given
price range.
This area includes the following:
• Authority key identifier: Identifies the public key to be used to verify the signature
on this certificate or CRL. Enables distinct keys of the same CA to be
differentiated. One use of this field is to handle CA key pair updating.
• Subject key identifier: Identifies the public key being certified. Useful for subject
key pair updating. Also, a subject may have multiple key pairs and, correspondingly,
different certificates for different purposes (e.g., digital signature
and encryption key agreement).
• Key usage: Indicates a restriction imposed as to the purposes for which, and
the policies under which, the certified public key may be used. May indicate
one or more of the following: digital signature, nonrepudiation, key encryption,
data encryption, key agreement, CA signature verification on certificates,
and CA signature verification on CRLs.
• Private-key usage period: Indicates the period of use of the private key corresponding
to the public key. Typically, the private key is used over a different
period from the validity of the public key. For example, with digital signature
keys, the usage period for the signing private key is typically shorter than that
for the verifying public key.
• Certificate policies: Certificates may be used in environments where multiple
policies apply. This extension lists policies that the certificate is recognized as
supporting, together with optional qualifier information.
• Policy mappings: Used only in certificates for CAs issued by other CAs. Policy
mappings allow an issuing CA to indicate that one or more of that issuer’s
policies can be considered equivalent to another policy used in the subject
CA’s domain.
37
Certificate Subject and Issuer Attributes
These extensions support alternative names, in alternative formats, for a certificate subject or certificate issuer and can convey additional information about the certificate subject to increase a certificate user’s confidence that the certificate subject is a particular person or entity
Includes:
Subject alternative name
Issuer alternative name
Subject directory attributes
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
These extensions support alternative
names, in alternative formats, for a certificate subject or certificate issuer and can
convey additional information about the certificate subject to increase a certificate
user’s confidence that the certificate subject is a particular person or entity. For
example, information such as postal address, position within a corporation, or
picture image may be required.
The extension fields in this area include the following:
• Subject alternative name: Contains one or more alternative names, using any
of a variety of forms. This field is important for supporting certain applications,
such as electronic mail, EDI, and IPSec, which may employ their own
name forms.
• Issuer alternative name: Contains one or more alternative names, using any of
a variety of forms.
• Subject directory attributes: Conveys any desired X.500 directory attribute
values for the subject of this certificate.
38
Certification Path Constraints
These extensions allow constraint specifications to be included in certificates issued for C As by other C As
The constraints may restrict the types of certificates that can be issued by the subject C A or that may occur subsequently in a certification chain
Includes:
Basic constraints
Name constraints
Policy constraints
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
These extensions allow constraint specifications
to be included in certificates issued for CAs by other CAs. The constraints may
restrict the types of certificates that can be issued by the subject CA or that may
occur subsequently in a certification chain.
The extension fields in this area include the following:
• Basic constraints: Indicates if the subject may act as a CA. If so, a certification
path length constraint may be specified.
• Name constraints: Indicates a name space within which all subject names in
subsequent certificates in a certification path must be located.
• Policy constraints: Specifies constraints that may require explicit certificate
policy identification or inhibit policy mapping for the remainder of the certification
path.
39
P K I X Architectural Model
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
40
RFC 4949 (Internet Security Glossary ) defines public-key infrastructure (PKI) as
the set of hardware, software, people, policies, and procedures needed to create,
manage, store, distribute, and revoke digital certificates based on asymmetric cryptography.
The principal objective for developing a PKI is to enable secure, convenient,
and efficient acquisition of public keys. The Internet Engineering Task Force
(IETF) Public Key Infrastructure X.509 (PKIX) working group has been the driving
force behind setting up a formal (and generic) model based on X.509 that is
suitable for deploying a certificate-based architecture on the Internet. This section
describes the PKIX model.
Figure 4.7 shows the interrelationship among the key elements of the PKIX
model. These elements are
• End entity: A generic term used to denote end users, devices (e.g., servers,
routers), or any other entity that can be identified in the subject field of a public
key certificate. End entities typically consume and/or support PKI-related
services.
• Certification authority (CA): The issuer of certificates and (usually) certificate
revocation lists (CRLs). It may also support a variety of administrative functions,
although these are often delegated to one or more registration authorities.
• Registration authority (RA): An optional component that can assume a number
of administrative functions from the CA. The RA is often associated with the
end entity registration process, but can assist in a number of other areas as well.
• CRL issuer: An optional component that a CA can delegate to publish CRLs.
• Repository: A generic term used to denote any method for storing certificates
and CRLs so that they can be retrieved by end entities.
P K I X Management Functions (1 of 2)
Functions that potentially need to be supported by management protocols:
Registration
Initialization
Certification
Key pair recovery
Key pair update
Revocation request
Cross certification
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
PKIX identifies a number of management functions that potentially need to be supported
by management protocols. These are indicated in Figure 4.7 and include the
following:
• Registration: This is the process whereby a user first makes itself known to
a CA (directly, or through an RA), prior to that CA issuing a certificate or
certificates for that user. Registration begins the process of enrolling in a PKI.
Registration usually involves some off-line or online procedure for mutual authentication.
Typically, the end entity is issued one or more shared secret keys
used for subsequent authentication.
• Initialization: Before a client system can operate securely, it is necessary to
install key materials that have the appropriate relationship with keys stored
elsewhere in the infrastructure. For example, the client needs to be securely
initialized with the public key and other assured information of the trusted
CA(s) to be used in validating certificate paths.
• Certification: This is the process in which a CA issues a certificate for a user’s
public key and returns that certificate to the user’s client system and/or posts
that certificate in a repository.
• Key pair recovery: Key pairs can be used to support digital signature creation
and verification, encryption and decryption, or both. When a key pair is used
for encryption/decryption, it is important to provide a mechanism to recover the
necessary decryption keys when normal access to the keying material is no longer
possible, otherwise it will not be possible to recover the encrypted data. Loss of
access to the decryption key can result from forgotten passwords/PINs, corrupted
disk drives, damage to hardware tokens, and so on. Key pair recovery allows end
entities to restore their encryption/decryption key pair from an authorized key
backup facility (typically, the CA that issued the end entity’s certificate).
• Key pair update: All key pairs need to be updated regularly (i.e., replaced
with a new key pair) and new certificates issued. Update is required when the
certificate lifetime expires and as a result of certificate revocation.
• Revocation request: An authorized person advises a CA of an abnormal situation
requiring certificate revocation. Reasons for revocation include private
key compromise, change in affiliation, and name change.
• Cross-certification: Two CAs exchange information used in establishing
a cross-certificate. A cross-certificate is a certificate issued by one CA to
another CA that contains a CA signature key used for issuing certificates.
The PKIX working group has defined two alternative management protocols
between PKIX entities that support the management functions listed in the preceding
subsection. RFC 2510 defines the certificate management protocols (CMP).
Within CMP, each of the management functions is explicitly identified by specific
protocol exchanges. CMP is designed to be a flexible protocol able to accommodate
a variety of technical, operational, and business models.
RFC 2797 defines certificate management messages over CMS (CMC), where
CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work
and is intended to leverage existing implementations. Although all of the PKIX functions
are supported, the functions do not all map into specific protocol exchanges.
41
P K I X Management Functions (2 of 2)
Alternative management protocols:
Certificate management protocols (C M P)
Designed to be a flexible protocol able to accommodate a variety of technical, operational, and business models
Certificate management messages over C M S (C M C)
Is built on earlier work and is intended to leverage existing implementations
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
PKIX identifies a number of management functions that potentially need to be supported
by management protocols. These are indicated in Figure 4.7 and include the
following:
• Registration: This is the process whereby a user first makes itself known to
a CA (directly, or through an RA), prior to that CA issuing a certificate or
certificates for that user. Registration begins the process of enrolling in a PKI.
Registration usually involves some off-line or online procedure for mutual authentication.
Typically, the end entity is issued one or more shared secret keys
used for subsequent authentication.
• Initialization: Before a client system can operate securely, it is necessary to
install key materials that have the appropriate relationship with keys stored
elsewhere in the infrastructure. For example, the client needs to be securely
initialized with the public key and other assured information of the trusted
CA(s) to be used in validating certificate paths.
• Certification: This is the process in which a CA issues a certificate for a user’s
public key and returns that certificate to the user’s client system and/or posts
that certificate in a repository.
• Key pair recovery: Key pairs can be used to support digital signature creation
and verification, encryption and decryption, or both. When a key pair is used
for encryption/decryption, it is important to provide a mechanism to recover the
necessary decryption keys when normal access to the keying material is no longer
possible, otherwise it will not be possible to recover the encrypted data. Loss of
access to the decryption key can result from forgotten passwords/PINs, corrupted
disk drives, damage to hardware tokens, and so on. Key pair recovery allows end
entities to restore their encryption/decryption key pair from an authorized key
backup facility (typically, the CA that issued the end entity’s certificate).
• Key pair update: All key pairs need to be updated regularly (i.e., replaced
with a new key pair) and new certificates issued. Update is required when the
certificate lifetime expires and as a result of certificate revocation.
• Revocation request: An authorized person advises a CA of an abnormal situation
requiring certificate revocation. Reasons for revocation include private
key compromise, change in affiliation, and name change.
• Cross-certification: Two CAs exchange information used in establishing
a cross-certificate. A cross-certificate is a certificate issued by one CA to
another CA that contains a CA signature key used for issuing certificates.
The PKIX working group has defined two alternative management protocols
between PKIX entities that support the management functions listed in the preceding
subsection. RFC 2510 defines the certificate management protocols (CMP).
Within CMP, each of the management functions is explicitly identified by specific
protocol exchanges. CMP is designed to be a flexible protocol able to accommodate
a variety of technical, operational, and business models.
RFC 2797 defines certificate management messages over CMS (CMC), where
CMS refers to RFC 2630, cryptographic message syntax. CMC is built on earlier work
and is intended to leverage existing implementations. Although all of the PKIX functions
are supported, the functions do not all map into specific protocol exchanges.
42
Identity Management (1 of 2)
A centralized, automated approach to provide enterprise wide access to resources by employees and other authorized individuals
Focus is defining an identity for each user (human or process), associating attributes with the identity, and enforcing a means by which a user can verify identity
Central concept is the use of single sign-on (S S O) which enables a user to access all network resources after a single authentication
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Federated identity management is a relatively new concept dealing with the use of
a common identity management scheme across multiple enterprises and numerous
applications and supporting many thousands, even millions, of users. We begin our
overview with a discussion of the concept of identity management and then examine
federated identity management.
Identity management is a centralized, automated approach to provide enterprise wide
access to resources by employees and other authorized individuals. The focus
of identity management is defining an identity for each user (human or process),
associating attributes with the identity, and enforcing a means by which a user can
verify identity. The central concept of an identity management system is the use
of single sign-on (SSO). SSO enables a user to access all network resources after a
single authentication.
Typical services provided by a federated identity management system include
the following:
■ Point of contact: Includes authentication that a user corresponds to the user
name provided, and management of user/server sessions.
■ SSO protocol services: Provides a vendor-neutral security token service for
supporting a single sign on to federated services.
■ Trust services: Federation relationships require a trust relationship-based
federation between business partners. A trust relationship is represented by
the combination of the security tokens used to exchange information about a
user, the cryptographic information used to protect these security tokens, and
optionally the identity mapping rules applied to the information contained
within this token.
■ Key services: Management of keys and certificates.
■ Identity services: Services that provide the interface to local data stores, including
user registries and databases, for identity-related information management.
■ Authorization: Granting access to specific services and/or resources based on
the authentication.
■ Provisioning: Includes creating an account in each target system for the user,
enrollment or registration of user in accounts, establishment of access rights
or credentials to ensure the privacy and integrity of account data.
■ Management: Services related to runtime configuration and deployment.
43
Identity Management (2 of 2)
Principal elements of an identity management system:
Authentication
Authorization
Accounting
Provisioning
Workflow automation
Delegated administration
Password synchronization
Self-service password reset
Federation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Federated identity management is a relatively new concept dealing with the use of
a common identity management scheme across multiple enterprises and numerous
applications and supporting many thousands, even millions, of users. We begin our
overview with a discussion of the concept of identity management and then examine
federated identity management.
Identity management is a centralized, automated approach to provide enterprise wide
access to resources by employees and other authorized individuals. The focus
of identity management is defining an identity for each user (human or process),
associating attributes with the identity, and enforcing a means by which a user can
verify identity. The central concept of an identity management system is the use
of single sign-on (SSO). SSO enables a user to access all network resources after a
single authentication.
Typical services provided by a federated identity management system include
the following:
■ Point of contact: Includes authentication that a user corresponds to the user
name provided, and management of user/server sessions.
■ SSO protocol services: Provides a vendor-neutral security token service for
supporting a single sign on to federated services.
■ Trust services: Federation relationships require a trust relationship-based
federation between business partners. A trust relationship is represented by
the combination of the security tokens used to exchange information about a
user, the cryptographic information used to protect these security tokens, and
optionally the identity mapping rules applied to the information contained
within this token.
■ Key services: Management of keys and certificates.
■ Identity services: Services that provide the interface to local data stores, including
user registries and databases, for identity-related information management.
■ Authorization: Granting access to specific services and/or resources based on
the authentication.
■ Provisioning: Includes creating an account in each target system for the user,
enrollment or registration of user in accounts, establishment of access rights
or credentials to ensure the privacy and integrity of account data.
■ Management: Services related to runtime configuration and deployment.
44
Figure 4-8: Generic Identity Management System
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
45
Figure 4.8 [LINN06] illustrates entities and data flows in a generic identity
management architecture. A principal is an identity holder. Typically, this is
a human user that seeks access to resources and services on the network. User
devices, agent processes, and server systems may also function as principals.
Principals authenticate themselves to an identity provider . The identity provider
associates authentication information with a principal, as well as attributes and one
or more identifiers.
Increasingly, digital identities incorporate attributes other than simply
an identifier and authentication information (such as passwords and biometric
information). An attribute service manages the creation and maintenance of such
attributes. For example, a user needs to provide a shipping address each time an
order is placed at a new Web merchant, and this information needs to be revised
when the user moves. Identity management enables the user to provide this information
once, so that it is maintained in a single place and released to data consumers
in accordance with authorization and privacy policies. Users may create
some of the attributes to be associated with their digital identity, such as address.
Administrators may also assign attributes to users, such as roles, access permissions,
and employee information.
Data consumers are entities that obtain and employ data maintained and provided
by identity and attribute providers, which are often used to support authorization
decisions and to collect audit information. For example, a database server or
file server is a data consumer that needs a client’s credentials so as to know what
access to provide to that client.
Identity Federation
Identity federation is, in essence, an extension of identity management to multiple security domains
Federated identity management refers to the agreements, standards, and technologies that enable the portability of identities, identity attributes, and entitlements across multiple enterprises and numerous applications and supports many thousands, even millions, of users
Another key function of federated identity management is identity mapping
The federated identity management protocols map identities and attributes of a user in one domain to the requirements of another domain
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Identity federation is, in essence, an extension of identity management to multiple
security domains. Such domains include autonomous internal business units,
external business partners, and other third-party applications and services. The
goal is to provide the sharing of digital identities so that a user can be authenticated
a single time and then access applications and resources across multiple
domains. Because these domains are relatively autonomous or independent, no
centralized control is possible. Rather, the cooperating organizations must form a
federation based on agreed standards and mutual levels of trust to securely share
digital identities.
Federated identity management refers to the agreements, standards, and
technologies that enable the portability of identities, identity attributes, and entitlements
across multiple enterprises and numerous applications and supports many
thousands, even millions, of users. When multiple organizations implement interoperable
federated identity schemes, an employee in one organization can use a single
sign-on to access services across the federation with trust relationships associated
with the identity. For example, an employee may log onto her corporate intranet
and be authenticated to perform authorized functions and access authorized services
on that intranet. The employee could then access her health benefits from an
outside health-care provider without having to reauthenticate.
Beyond SSO, federated identity management provides other capabilities. One
is a standardized means of representing attributes. Increasingly, digital identities
incorporate attributes other than simply an identifier and authentication information
(such as passwords and biometric information). Examples of attributes include
account numbers, organizational roles, physical location, and file ownership. A user
may have multiple identifiers; for example, each identifier may be associated with a
unique role with its own access permissions.
Another key function of federated identity management is identity mapping.
Different security domains may represent identities and attributes differently.
Furthermore, the amount of information associated with an individual in one
domain may be more than is necessary in another domain. The federated identity
management protocols map identities and attributes of a user in one domain to the
requirements of another domain.
46
Federated Identity Operation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Figure 4.9 illustrates entities and data flows in a generic federated identity
management architecture.
The identity provider acquires attribute information through dialogue and
protocol exchanges with users and administrators. For example, a user needs to
provide a shipping address each time an order is placed at a new Web merchant,
and this information needs to be revised when the user moves. Identity management
enables the user to provide this information once, so that it is maintained in a
single place and released to data consumers in accordance with authorization and
privacy policies.
Service providers are entities that obtain and employ data maintained and provided
by identity providers, often to support authorization decisions and to collect
audit information. For example, a database server or file server is a data consumer
that needs a client’s credentials so as to know what access to provide to that client.
A service provider can be in the same domain as the user and the identity provider.
The power of this approach is for federated identity management, in which the service
provider is in a different domain (e.g., a vendor or supplier network).
47
Standards (1 of 2)
The Extensible Markup Language (X M L)
Appear similar to H T M L documents that are visible as Web pages, but provide greater functionality
Includes strict definitions of the data type of each field
Provides encoding rules for commands that are used to transfer and update data objects
The Simple Object Access Protocol (S O A P)
Minimal set of conventions for invoking code using XML over H T T P
Enables applications to request services from one another with X M L-based requests and receive responses as data formatted with X M L
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Federated identity management uses a number of standards as the
building blocks for secure identity exchange across different domains or heterogeneous
systems. In essence, organizations issue some form of security tickets for their
users that can be processed by cooperating partners. Identity federation standards
are thus concerned with defining these tickets in terms of content and format, providing
protocols for exchanging tickets, and performing a number of management
tasks. These tasks include configuring systems to perform attribute transfers and
identity mapping, and performing logging and auditing functions. The key standards
are as follows:
• The Extensible Markup Language (XML): A markup language uses sets of
embedded tags or labels to characterize text elements within a document so as
to indicate their appearance, function, meaning, or context. XML documents
appear similar to HTML (Hypertext Markup Language) documents that are
visible as Web pages, but provide greater functionality. XML includes strict
definitions of the data type of each field, thus supporting database formats
and semantics. XML provides encoding rules for commands that are used to
transfer and update data objects.
• The Simple Object Access Protocol (SOAP): A minimal set of conventions
for invoking code using XML over HTTP. It enables applications to request
services from one another with XML-based requests and receive responses
as data formatted with XML. Thus, XML defines data objects and structures,
and SOAP provides a means of exchanging such data objects and performing
remote procedure calls related to these objects. See [ROS06] for an informative
discussion.
• WS-Security: A set of SOAP extensions for implementing message integrity
and confidentiality in Web services. To provide for secure exchange of SOAP
messages among applications, WS-Security assigns security tokens to each
message for use in authentication.
• Security Assertion Markup Language (SAML): An XML-based language for
the exchange of security information between online business partners. SAML
conveys authentication information in the form of assertions about subjects.
Assertions are statements about the subject issued by an authoritative entity.
The challenge with federated identity management is to integrate multiple
technologies, standards, and services to provide a secure, user-friendly utility. The
key, as in most areas of security and networking, is the reliance on a few mature
standards widely accepted by industry. Federated identity management seems to
have reached this level of maturity.
48
Standards (2 of 2)
W S-Security
A set of S O A P extensions for implementing message integrity and confidentiality in Web services
Assigns security tokens to each message for use in authentication
Security Assertion Markup Language (S A M L)
An X M L-based language for the exchange of security information between online business partners
Conveys authentication information in the form of assertions about subjects
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Federated identity management uses a number of standards as the
building blocks for secure identity exchange across different domains or heterogeneous
systems. In essence, organizations issue some form of security tickets for their
users that can be processed by cooperating partners. Identity federation standards
are thus concerned with defining these tickets in terms of content and format, providing
protocols for exchanging tickets, and performing a number of management
tasks. These tasks include configuring systems to perform attribute transfers and
identity mapping, and performing logging and auditing functions. The key standards
are as follows:
• The Extensible Markup Language (XML): A markup language uses sets of
embedded tags or labels to characterize text elements within a document so as
to indicate their appearance, function, meaning, or context. XML documents
appear similar to HTML (Hypertext Markup Language) documents that are
visible as Web pages, but provide greater functionality. XML includes strict
definitions of the data type of each field, thus supporting database formats
and semantics. XML provides encoding rules for commands that are used to
transfer and update data objects.
• The Simple Object Access Protocol (SOAP): A minimal set of conventions
for invoking code using XML over HTTP. It enables applications to request
services from one another with XML-based requests and receive responses
as data formatted with XML. Thus, XML defines data objects and structures,
and SOAP provides a means of exchanging such data objects and performing
remote procedure calls related to these objects. See [ROS06] for an informative
discussion.
• WS-Security: A set of SOAP extensions for implementing message integrity
and confidentiality in Web services. To provide for secure exchange of SOAP
messages among applications, WS-Security assigns security tokens to each
message for use in authentication.
• Security Assertion Markup Language (SAML): An XML-based language for
the exchange of security information between online business partners. SAML
conveys authentication information in the form of assertions about subjects.
Assertions are statements about the subject issued by an authoritative entity.
The challenge with federated identity management is to integrate multiple
technologies, standards, and services to provide a secure, user-friendly utility. The
key, as in most areas of security and networking, is the reliance on a few mature
standards widely accepted by industry. Federated identity management seems to
have reached this level of maturity.
49
Figure 4-10: Federated Identity Scenarios
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
50
To get some feel for the functionality of identity federation, we look
at three scenarios, taken from [COMP06]. In the first scenario (Figure 4.10a),
Workplace.com contracts with Health.com to provide employee health benefits.
An employee uses a Web interface to sign on to Workplace.com and goes through
an authentication procedure there. This enables the employee to access authorized
services and resources at Workplace.com. When the employee clicks on a
link to access health benefits, her browser is redirected to Health.com. At the same
time, the Workplace.com software passes the user’s identifier to Health.com in a
secure manner. The two organizations are part of a federation that cooperatively
exchanges user identifiers. Health.com maintains user identities for every employee
at Workplace.com and associates with each identity health-benefits information
and access rights. In this example, the linkage between the two companies is based
on account information and user participation is browser based.
Figure 4.10b shows a second type of browser-based scheme. PartsSupplier.
com is a regular supplier of parts to Workplace.com. In this case, a role-based
access control (RBAC) scheme is used for access to information. An engineer of
Workplace.com authenticates at the employee portal at Workplace.com and clicks
on a link to access information at PartsSupplier.com. Because the user is authenticated
in the role of an engineer, he is taken to the technical documentation and
troubleshooting portion of PartSupplier.com’s Web site without having to sign
on. Similarly, an employee in a purchasing role signs on at Workplace.com and is
authorized, in that role, to place purchases at PartSupplier.com without having to
authenticate to PartSupplier.com. For this scenario, PartSupplier.com does not
have identity information for individual employees at Workplace.com. Rather, the
linkage between the two federated partners is in terms of roles.
The scenario illustrated in Figure 4.10c can be referred to as document based
rather than browser based. In this third example, Workplace.com has a purchasing
agreement with PinSupplies.com, and PinSupplies.com has a business relationship
with E-Ship.com. An employee of Workplace.com signs on and is authenticated to
make purchases. The employee goes to a procurement application that provides a
list of Workplace.com’s suppliers and the parts that can be ordered. The user clicks
on the PinSupplies button and is presented with a purchase order Web page (HTML
page). The employee fills out the form and clicks the submit button. The procurement
application generates an XML/SOAP document that it inserts into the envelope
body of an XML-based message. The procurement application then inserts the
user’s credentials in the envelope header of the message, together with Workplace.
com’s organizational identity. The procurement application posts the message to the
PinSupplies.com’s purchasing Web service. This service authenticates the incoming
message and processes the request. The purchasing Web service then sends a SOAP
message its shipping partner to fulfill the order. The message includes a PinSupplies.
com security token in the envelope header and the list of items to be shipped as well
as the end user’s shipping information in the envelope body. The shipping Web
service authenticates the request and processes the shipment order.
Summary (1 of 2)
Remote user authentication principles
The N I S T model for electronic user authentication
Means of authentication
Symmetric key distribution using symmetric encryption
Kerberos
Version 4
Version 5
Key distribution using asymmetric encryption
Public-key certificates
Public-key distribution of secret keys
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Chapter 4 summary.
51
Summary (2 of 2)
X.509 certificates
Certificates
X.509 Version 3
Public-key infrastructure
P K I X management functions
P K I X management protocols
Federated identity management
Identity management
Identity federation
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
Chapter 4 summary.
52
Copyright
Copyright © 2017 Pearson Education, Inc. All Rights Reserved
53
N e
tw o
rk S
e c u rity
E s s e
n tia
ls Applications and Standards
S ixth
E d
itio n
S T A
L L IN
G S
c
ID
tgs
ID
1
TS
c
K
ctgs
K
tgs
ID
2
TS
2
Lifetime
tgs
Ticket
v
ID
tgs
Ticket
c
tor
Authentica
ctgs
K
v
,
c
K
v
ID
4
TS
v
Ticket
tgs
Ticket
tgs
K
ctgs
K
c
ID
c
AD
tgs
ID
2
TS
2
Lifetime
c
tor
Authentica
ctgs
K
c
ID
c
AD
3
TS
v
Ticket
c
tor
Authentica
v
c,
K
1
5
TS
+
v
Ticket
v
K
v
c,
K
c
ID
5
TS
c
AD
v
ID
4
TS
4
Lifetime
c
tor
Authentica
v
c,
K
c
ID
c
AD
