Cryptograph

y and
Network
Security
Sixth Edition
by William Stallings
Chapter 15
User Authentication
“Badges? We ain’t got no badges!
We don’t need no badges! I don’t
have to show you any stinking
badges!”

—The Treasure of the Sierra

Madre,
 Remote User-
Authentication Principles
• The process of verifying an identity claimed by
or for a system entity
• An authentication process consists of two
steps:

Verificatio
• Presenting an n step
identifier to the • Presenting or
security system generating
authentication
information that
Identificati corroborates the
on step binding between the
entity and the identifier
 Means of User
Authentication
Something the individual Something the individual
knows possesses
• Examples include a password, • Examples include
a personal identification cryptographic keys, electronic
number (PIN), or answers to a are keycards,
There four
smart cards, and
prearranged set of questions physical
general means of keys
• This
authenticating a is referred to as a token
user’s identity,
which can be used
alone or in
combination
Something the individual is Something the individual
(static biometrics) does (dynamic biometrics)
• Examples include recognition • Examples include recognition
by fingerprint, retina, and by voice pattern, handwriting
face characteristics, and typing
rhythm

• For network-based user authentication, the most

important methods involve cryptographic keys and
something the individual knows, such as a password
 Mutual
Authentication
• Protocols which enable communicating parties to
satisfy themselves mutually about each other’s
identity and to exchange session keys
Central to the
problem of
authenticate
d key
exchange are
two issues:
Timeliness
• Important because of the
threat of message replays Confidentiality
• Such replays could allow • Essential identification
an opponent to: and session-key
• compromise a session key information must be
• successfully impersonate communicated in
another party encrypted form
• disrupt operations by • This requires the prior
presenting parties with existence of secret or
messages that appear public keys that can
genuine but are not be used for this
purpose
 Replay Attacks
1. The simplest replay attack is one in which the opponent
simply copies a message and replays it later

2. An opponent can replay a timestamped message within

the valid time window. If both the original and the replay
arrive within then time window,this incident can be logged

3. An opponent can replay a timestamped message within

the valid time window, but in addition, the opponent
suppresses the original message; thus, the repetition
cannot be detected

4. Another attack involves a backward replay without

modification and is possible if symmetric encryption is
used and the sender cannot easily recognize the
difference between messages sent and messages
received on the basis of content
 Approaches to
Coping With Replay
Attacks
• Attach a sequence number to each message used in an
authentication exchange
• A new message is accepted only if its sequence number is in the
proper order
• Difficulty with this approach is that it requires each party to keep
track of the last sequence number for each claimant it has dealt
with
• Generally not used for authentication and key exchange because of
overhead

• Timestamps
• Requires that clocks among the various participants be synchronized
• Party A accepts a message as fresh only if the message contains a
timestamp that, in A’s judgment, is close enough to A’s knowledge
of current time

• Challenge/response
• Party A, expecting a fresh message from B, first sends B a nonce
(challenge) and requires that the subsequent message (response)
 One-Way
Authentication
One application for
which encryption is A second requirement
growing in popularity is is that of
electronic mail (e- authentication
mail)
• Header of the e-mail • The recipient wants some
message must be in the assurance that the
clear so that the message is from the
message can be handled alleged sender
by the store-and-forward
e-mail protocol, such
as SMTP or X.400
• The e-mail message
should be encrypted such
that the mail-handling
system is not in
possession of the
decryption key
Remote User-Authentication
Using Symmetric Encryption
A two-level hierarchy of symmetric keys
can be used to provide confidentiality
for communication in a distributed
environment
• Strategy involves the use of a trusted key
distribution center (KDC)
• Each party shares a secret key, known as a
master key, with the KDC
• KDC is responsible for generating keys to
be used for a short time over a connection
between two parties and for distributing
those keys using the master keys to protect
the distribution
Needham and
Schroeder
 Suppress-Replay
Attacks
• The Denning protocol requires reliance on clocks
that are synchronized throughout the network
• A risk involved is based on the fact that the
distributed clocks can become unsynchronized as a
result of sabotage on or faults in the clocks or the
synchronization mechanism
• The problem occurs when a sender’s clock is ahead
of the intended recipient’s clock
• An opponent can intercept a message from the
sender and replay it later when the timestamp in the
message becomes current at the recipient’s site
• Such attacks are referred to as suppress-replay
attacks
Counter measures
suppress replay
attack
 Kerberos
• Authentication service developed as part of Project Athena at
MIT
• A workstation cannot be trusted to identify its users correctly
to network services
• A user may gain access to a particular workstation and pretend
to be another user operating from that workstation
• 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
• A user may eavesdrop on exchanges and use a replay attack to
gain entrance to a server or to disrupt operations

• Kerberos 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
 Kerberos
Requirements
• The first published report on Kerberos listed
the following requirements:
• A network • Should be highly
eavesdropper should reliable and
not be able to obtain should employ a
the necessary distributed server
information to architecture with
impersonate a user one system able
Secure Reliable to back up
another

Transpar
Scalable
ent

• The system should • Ideally, the user should not

be capable of be aware that authentication
supporting large is taking place beyond the
numbers of clients requirement to enter a
and servers password
 Kerberos Version 4
• Makes use of DES to provide the authentication service

• Authentication server (AS)

• Knows the passwords of all users and stores these in a
centralized database
• Shares a unique secret key with each server

• Ticket
• Created once the AS accepts the user as authentic; contains the
user’s ID and network address and the server’s ID
• Encrypted using the secret key shared by the AS and the server

• Ticket-granting server (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
 Simple
authentication
dialogue
 Secure
authentication
dialogue
 Issues with TGS
• No sort means that the user using the
ticket is the same who request the
ticket

• No policies for the authenticating the

server.
• Chances for False server
 The Version 4
Authentication
Dialogue
The lifetime associated with
the ticket-granting ticket A network service (the TGS or
creates a problem: an application service) must
• If the lifetime is very short (e.g., be able to prove that the
minutes), the user will be repeatedly person using a ticket is the
asked for a password
• If the lifetime is long (e.g., hours), then same person to whom that
an opponent has a greater opportunity ticket was issued
for replay

Servers need to authenticate

themselves to users
 Table 15.1 (page 464 in textbook)
Summary of Kerberos Version 4 Message
Exchanges
This table can be found on pages 467 – 468 in the textbook)
(page 3 of 3)
 Kerberos Realms
and Multiple Kerberi
• A full-service Kerberos environment consisting of
a Kerberos server, a number of clients, and a
number of application servers requires that:
• 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
• The Kerberos server must share a secret key with
each server; all servers are registered with the
Kerberos server
• The Kerberos server in each interoperating realm
shares a secret key with the server in the other
realm; the two Kerberos servers are registered with
each other
 Kerberos Realm
• A set of managed nodes that share the same
Kerberos database
• The 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
 Kerberos Principal

• A service or user A
service
that is known to An
or user
instan
the Kerberos ce name
name
system
A
realm
• Identified by its name
principal name

Three parts of a
principal name
Differences Between
Versions 4 and 5
Version 5 is intended to
address the limitations of
version 4 in two areas:
Environmental Technical deficiencies
shortcomings • Double encryption
• Encryption system • PCBC encryption
dependence • Session keys
• Internet protocol dependence • Password attacks
• Message byte ordering
• Ticket lifetime
• Authentication forwarding
 Encryption system
dependence
• Kerberos version 4 relied on a single
encryption algorithm (DES) that became
restricted and potentially weak.

• Version 5 addressed this by allowing any

encryption method to be used, identified within
the encrypted data.

• Key flexibility was also introduced, enabling

the same key to work with different algorithms
or variations.
 Internet protocol
dependence
• Version 4 requires the use of Internet
Protocol (IP) addresses. Other address
types, such as the ISO network address, are
not accommodated. Version 5 network
addresses are tagged with type and
length,allowing any network address type to
be used.
 Message byte
ordering
• Version 4: The writer could choose how
to order the letters (big-endian or little-
endian) and then he has to give a
note like read this from left to right" or
"read this right to left".

• Version 5: Now messages are like

printed books, with a clear and
standard way of ordering the
information (using ASN.1 and BER) so
everyone can understand them easily.
 Ticket lifetime
• Ticket lifetime: Lifetime values in
version 4 are encoded in an 8-bit
quantity in units of five minutes. Thus,
the maximum lifetime that can be
expressed is 28 * 5 = 1280 minutes
(a little over 21 hours). This may be
inadequate for some applications (e.g.,
a long-running simulation that requires
valid kerberoscredentials throughout
execution). In version 5, tickets include
an explicit start time and end time,
allowing tickets with arbitrary lifetimes.
 Authentication
forwarding
• Not supported in K4, but it is
supported in K5

• Version 4 does not allow credentials

issued to one client to be forwarded to
some other host and used by some
other client.

• Interrealm authentication: In version 4,

interoperability among realms requires
on the order of Kerberos-to-Kerberos
relationships,
 Technical
deficiencies
• PCBC encryption: Encryption in version
4 makes use of a nonstandard mode of
DES known as propagating cipher block
chaining . Version 5 use CBC
• Session keys: Each ticket includes a
session key that is used by the client to
encrypt the authenticator sent to the
service associated with that ticket. In
addition, the session key may
subsequently be used by the client and
the server to protect messages passed
 Password attack
• Both versions of vulnerable to
password attack.
 Table 15.3
Summary of Kerberos Version 5 Message
Exchanges
Table 15.4

Kerberos
Version 5
Flags

(Table can be found

on page 474 in
textbook)
 Mutual
Authentication
• Public-key encryption for session key distribution
• Assumes each of the two parties is in possession
of the current public key of the other
• May not be practical to require this assumption

• Denning protocol using timestamps

• Uses an authentication server (AS) to provide
public-key certificates
• Requires the synchronization of clocks

• Woo and Lam makes use of nonces

• Care needed to ensure no protocol flaws
 One-Way
Authentication
• Have public-key approaches for e-mail
• Encryption of message for confidentiality,
authentication, or both
• The public-key algorithm must be applied
once or twice to what may be a long
message

• For confidentiality encrypt message with

one-time secret key, public-key encrypted
• If authentication is the primary concern, a
digital signature may suffice
 Federated Identity
Management
• Relatively new concept dealing with the use of a
common identity management scheme across
multiple enterprise and numerous applications and
supporting many users
• Services provided include:
• Point of contact
• SSO protocol services
• Trust services
• Key services
• Identity services
• Authorization
• Provisioning
• Management
 Key Standards
Security
The Extensible The Simple
Assertion
Markup Object Access
WS-Security Markup
Language Protocol
Language
(XML) (SOAP)
(SAML)
A markup
language that
Enables
uses sets of
applications
embedded
to request An XML-based
tags or labels A set of SOAP
services from language for
to extensions for
one another the exchange
characterize implementing
with XML- of security
text elements message
based information
within a integrity and
requests and between
document so confidentiality
receive online
as to indicate in Web
responses as business
their services
data partners
appearance,
formatted
function,
with XML
meaning, or
context
 Personal Identity
Verification
• User authentication based on the possession of a smart
card is becoming more widespread
• Has the appearance of a credit card
• Has an electronic interface
• May use a variety of authentication protocols

• A smart card contains within it an entire microprocessor,

including processor, memory, and I/O ports
• A smart card includes three types of memory:
• Read-only memory (ROM) stores data that does not change
during the card’s life
• Electronically erasable programmable ROM (EEPROM) holds
application data and programs; also holds data that may
vary with time
• Random access memory (RAM) holds temporary data
generated when applications are executed
 PIV Documentation
• FIPS 201-2—Personal Identity Verification
• SP 800-104—A Scheme for PIV Visual
(PIV) of Federal Employees and Card Topography
Contractors • Provides additional recommendations
• Specifies the physical card characteristics, on the PIV card color-coding for
storage media, and data elements that designating employee affiliation
make up the identity credentials resident
• SP 800-116—A Recommendation for
on the PIV card
the Use of PIV Credentials in Physical
• SP 800-73-3—Interfaces for Personal Access Control Systems (PACS)
Identity Verification
• Describes a risk-based approach for
• Specifies the interfaces and card architecture
for storing and retrieving identity credentials selecting appropriate PIV
from a smart card, and provides guidelines authentication mechanisms to
for the use of authentication mechanisms and manage physical access to Federal
protocols government facilities and assets
• SP 800-76-2—Biometric Data Specification • SP 800-79-1—Guidelines for the
for Personal Identity Verification Accreditation of Personal Identity
• Describes technical acquisition and Verification Card Issuers
formatting specifications for the biometric
• Provides guidelines for accrediting the
credentials of the PIV system
reliability of issuers of PIV cards that
• SP 800-78-3—Cryptographic Algorithms collect, store, and disseminate
and Key Sizes for Personal Identity
personal identity credentials and issue
Verification
smart cards
• Identifies acceptable symmetric and
asymmetric encryption algorithms, digital • SP 800-96—PIV Card to Reader
signature algorithms, and message digest Interoperability Guidelines
algorithms, and specifies mechanisms to • Provides requirements that facilitate
identify the algorithms associated with PIV interoperability between any card and
keys or digital signatures
any reader
 PIV Credentials and
Keys
• Personal Identification Number (PIN) • Optional elements include the
• Required to activate the card for following:
privileged operation
• Digital Signature Key
• Cardholder Unique Identifier (CHUID) • Asymmetric key pair and
• corresponding certificate that
Includes the Federal Agency Smart
Credential Number (FASC-N) and the supports document signing and
Global Unique Identification Number signing of data elements such as the
(GUID), which uniquely identify the CHUID
card and the cardholder
• Key Management Key
• PIV Authentication Key • Asymmetric key pair and
corresponding certificate supporting
• Asymmetric key pair and key establishment and transport
corresponding certificate for user
authentication
• Symmetric Card Authentication
Key
• Two fingerprint templates • For supporting physical access
• For biometric authentication applications

• PIV Card Application

• Electronic facial image Administration Key
• For biometric authentication • Symmetric key associated with the
card management system
• Asymmetric Card Authentication Key
• One or two iris images
• Asymmetric key pair and
corresponding certificate used for • For biometric authentication
card authentication
 Table 15.5
PIV Algorithms and Key Sizes
 Authentication
• Using the electronic credentials • BIO
resident on a PIV card, the card The cardholder is authenticated by matching his
supports the following or her fingerprint sample(s) to the signed
authentication mechanisms: biometric data element in an environment
without a human attendant in view. The PIN is
required to activate the card. This mechanism
• CHUID achieves a high level of assurance and requires
The cardholder is authenticated the cardholder’s active participation is submitting
using the signed CHUID data the PIN as well as the biometric sample
element on the card. The PIN is not
required. This mechanism is useful • BIO-A
in environments where a low level of
The cardholder is authenticated by matching his
assurance is acceptable and rapid
or her fingerprint sample(s) to the signed
contactless authentication is
biometric data element in an environment with a
necessary
human attendant in view. The PIN is required to
activate the card. This mechanism achieves a
very high level of assurance when coupled with
• Card Authentication Key full trust validation of the biometric template
retrieved from the card, and requires the
The PIV card is authenticated using
cardholder’s active participation is submitting the
the Card Authentication Key in a
PIN as well as the biometric sample
challenge response protocol. The
PIN is not required. This mechanism
allows contact (via card reader) or
contactless (via radio waves) • PKI
authentication of the PIV card The cardholder is authenticated by
without the holder’s active demonstrating control of the PIV authentication
participation, and provides a low private key in a challenge response protocol that
level of assurance can be validated using the PIV authentication
certificate. The PIN is required to activate the
card. This mechanism achieves a very high level
of identity assurance and requires the
 Summary
• Remote user-
• Remote user-
authentication using
authentication asymmetric encryption
principles • Mutual authentication
• Mutual authentication • One-way authentication
• One-way
• Federated identity
authentication
management
• Identity management
• Remote user-
• Identity federation
authentication using
symmetric encryption • Personal identity
• Mutual authentication verification
• One-way • PIV system model
authentication • PIV documentation
• PIV credentials and keys
• Kerberos • authentication