Chapter 15

User Authentication

2015. 04. 06

Jae Woong Joo

SeoulTech
(woong07@seoultech.ac.kr)
 Table of Contents
15.1 Remote User-Authentication Principles

15.2 Remote User-Authentication Using Symmetric Encryption

15.3 Kerberos

15.4 Remote User Authentication Using Asymmetric Encryption

15.5 Federated Identity Management

15.6 Personal Identity Verification

2
 Introduction
• This chapter examines some of the authentication
functions that have been developed to support network-
based use authentication.

3
15.1 Remote User-Authentication Principles
 Remote User-Authentication Principles

• fundamental security building block

• basis of access control & user accountability
• is the process of verifying an identity
claimed by or for a system entity
• has two steps:
• identification - specify identifier
• verification - bind entity (person) and
identifier
• distinct from message authentication

5
 Means of User Authentication

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 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

For network-based user authentication, the most important methods

involve cryptographic keys and something the individual knows,
such as a password

6
 Mutual Authentication

• used to convince parties of each others

identity and to exchange session keys
• may be one-way or mutual
• key issues are
– confidentiality – to protect session keys
– timeliness – to prevent replay attacks

7
 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
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
8
 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) received from B contain
the correct nonce value

9
 One-Way Authentication

• required when sender & receiver are not in

communications at same time (eg. email)
• have header in clear so can be delivered by email
system
• may want contents of body protected & sender
authenticated

10
15.2 Remote User-Authentication Using
Symmetric Encryption
 Mutual Authentication

• 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

12
Mutual Authentication

13
 Mutual Authentication

• Denning [DENN81, DENN82] proposes to overcome this

weakness by a modification to the Needham/Schroeder
protocol that includes the addition of a timestamp to steps 2
and 3
• T is a timestamp that assures A and B that the session key
has only just been generated. Thus, both A and B know that
the key distribution is a fresh exchange. A and B can verify
timeliness by checking that

14
 Mutual Authentication

• In [KEHN92], an attempt is made to respond to the concerns

about suppressreplay attacks and at the same time fix the
problems in the Needham/Schroeder protocol. Subsequently,
an inconsistency in this latter protocol was noted and an
improved strategy was presented in [NEUM93a]

15
 Mutual Authentication

• This protocol provides an effective, secure means for A and B

to establish a session with a secure session key

16
 One-Way Authentication

• This scheme requires the sender to issue a request to the

intended recipient, await a response that includes a session
key, and only then send the message.

17
15.3 Kerberos
 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
19
 Kerberos Requirements
• its first report identified requirements as:
– Secure : A network eavesdropper should not be able
to obtain the necessary information to impersonate a
user
– Reliable : Should be highly reliable and should
employ a distributed server architecture with one
system able to back up another
– Transparent : Ideally, the user should not be aware
that authentication is taking place beyond the
requirement to enter a password
– Scalable : The system should be capable of
supporting large numbers of clients and servers

• implemented using an authentication protocol

based on Needham-Schroeder

20
 Kerberos Version 4

• a basic third-party authentication scheme

• have an Authentication Server (AS)
– users initially negotiate with AS to identify self
– AS provides a non-corruptible authentication
credential (ticket granting ticket TGT)
• have a Ticket Granting server (TGS)
– users subsequently request access to other
services from TGS on basis of users TGT
• using a complex protocol using DES

21
Summary of Kerberos Version 4 Message
Exchanges

22
Summary of Kerberos
Overview of Kerberos Version 4 Message
Exchanges

23
Summary of Kerberos
Overview of Kerberos Version 4 Message
Exchanges

24
Rationale for the Elements of the Kerberos
Version 4 Protocol

25
26
27
 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

28
Kerberos
Realms
 Kerberos Version 5
• developed in mid 1990’s
• specified as Internet standard RFC 1510
• provides improvements over v4
– addresses environmental shortcomings
• encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
– and technical deficiencies
• double encryption, non-std mode of use, session
keys, password attacks
 Kerberos Version 5
• Encryption system dependence: In version 5, ciphertext is tagged
with an encryption-type identifier so that any encryption technique
may be used
• Internet protocol dependence: Version 5 network addresses are
tagged with type and length, allowing any network address type to
be used.
• Message byte ordering: In version 5, all message structures are
defined using Abstract Syntax Notation One (ASN.1) and Basic
Encoding Rules (BER), which provide an unambiguous byte
ordering.
• Ticket lifetime:tickets include an explicit start time and end time,
allowing tickets with arbitrary lifetimes.
• Authentication forwarding:Version 5 does not allow credentials
issued to one client to be forwarded to some other host and used by
some other client.
• Interrealm authentication:Version 5 supports a method that
requires fewer relationships, as described shortly.
 Kerberos Version 5, technical deficiencies
• Double encryption:tickets provided to clients are encrypted twice,
The second encryption is not necessary and is computationally
wasteful.
• PCBC encryption:Version 5 provides explicit integrity mechanisms,
allowing the standard CBC mode to be used for encryption. In
particular, a checksum or hash code is attached to the message
prior to encryption using CBC.
• Session keys:In version 5, it is possible for a client and server to
negotiate a subsession key, which is to be used only for that one
connection. A new access by the client would result in the use of a
new subsession key.
• Password attacks: versions are vulnerable to a 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)
15.4 Remote User Authentication Using
Asymmetric Encryption
 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
15.5 Federated Identity Management
Federated Identity Management

• use of common identity management scheme

• across multiple enterprises & numerous
applications
• supporting many thousands, even millions of
users
• principal elements are:
• authentication, authorization, accounting,
provisioning, workflow automation, delegated
administration, password synchronization, self-
service password reset, federation
• Kerberos contains many of these elements
Federated Identity Management

Figure 15.4 Generic Identity Management Architecture

Identity Federation
 Key Standards
• The Extensible Markup Language (XML)
– A markup language that uses sets of embedded tags or labels to
characterize text elements within a document so as to indicate
their appearance, function, meaning, or context
• The Simple Object Access Protocol (SOAP)
– Enables applications to request services from one another with
XML-based requests and receive responses as data formatted
with XML
• WS-Security
– A set of SOAP extensions for implementing message integrity
and confidentiality in Web services
• Security Assertion Markup Language (SAML)
– An XML-based language for the exchange of security
information between online business partners
Figure 15.6 Federated Identity Scenarios
15.6 Personal Identity Verification
 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
• SP 800-104—A Scheme for PIV Visual Card
• FIPS 201-2—Personal Identity Verification (PIV) Topography
of Federal Employees and Contractors
– Provides additional recommendations on
– Specifies the physical card characteristics, the PIV card color-coding for designating
storage media, and data elements that make employee affiliation
up the identity credentials resident on the
PIV card • SP 800-116—A Recommendation for the Use
of PIV Credentials in Physical Access Control
• SP 800-73-3—Interfaces for Personal Identity Systems (PACS)
Verification
– Describes a risk-based approach for
– Specifies the interfaces and card selecting appropriate PIV authentication
architecture for storing and retrieving identity mechanisms to manage physical access to
credentials from a smart card, and provides Federal government facilities and assets
guidelines for the use of authentication
mechanisms and protocols • SP 800-79-1—Guidelines for the Accreditation
of Personal Identity Verification Card Issuers
• SP 800-76-2—Biometric Data Specification for
Personal Identity Verification – Provides guidelines for accrediting the
reliability of issuers of PIV cards that
– Describes technical acquisition and collect, store, and disseminate personal
formatting specifications for the biometric identity credentials and issue smart cards
credentials of the PIV system
• SP 800-96—PIV Card to Reader
• SP 800-78-3—Cryptographic Algorithms and Interoperability Guidelines
Key Sizes for Personal Identity Verification
– Provides requirements that facilitate
– Identifies acceptable symmetric and interoperability between any card and any
asymmetric encryption algorithms, digital reader
signature algorithms, and message digest
algorithms, and specifies mechanisms to
identify the algorithms associated with PIV
keys or digital signatures
 PIV Credentials and Keys
• Personal Identification Number (PIN) • Optional elements include the
– Required to activate the card for privileged following:
operation
• Cardholder Unique Identifier (CHUID) • Digital Signature Key
– Includes the Federal Agency Smart – Asymmetric key pair and
Credential Number (FASC-N) and the corresponding certificate that
Global Unique Identification Number supports document signing and
(GUID), which uniquely identify the card signing of data elements such as
and the cardholder the CHUID
• PIV Authentication Key • Key Management Key
– Asymmetric key pair and corresponding
certificate for user authentication – Asymmetric key pair and
corresponding certificate supporting
• Two fingerprint templates key establishment and transport
– For biometric authentication
• Electronic facial image • Symmetric Card Authentication
– For biometric authentication Key
• Asymmetric Card Authentication Key – For supporting physical access
– Asymmetric key pair and corresponding
applications
certificate used for card authentication • PIV Card Application
Administration Key
– Symmetric key associated with the
card management system
• One or two iris images
– For biometric authentication
 Table 15.5
PIV Algorithms and Key Sizes
 Authentication
• Using the electronic credentials resident • BIO
on a PIV card, the card supports the The cardholder is authenticated by matching his or her
following authentication mechanisms: fingerprint sample(s) to the signed biometric data
element in an environment without a human attendant
in view. The PIN is required to activate the card. This
– CHUID mechanism achieves a high level of assurance and
The cardholder is authenticated using requires the cardholder’s active participation is
the signed CHUID data element on the submitting the PIN as well as the biometric sample
card. The PIN is not required. This
mechanism is useful in environments – BIO-A
where a low level of assurance is The cardholder is authenticated by matching his or her
acceptable and rapid contactless fingerprint sample(s) to the signed biometric data
authentication is necessary element in an environment with a human attendant in
view. The PIN is required to activate the card. This
– Card Authentication Key mechanism achieves a very high level of assurance
when coupled with full trust validation of the biometric
The PIV card is authenticated using the template retrieved from the card, and requires the
Card Authentication Key in a challenge cardholder’s active participation is submitting the PIN
response protocol. The PIN is not as well as the biometric sample
required. This mechanism allows
contact (via card reader) or contactless • PKI
(via radio waves) authentication of the The cardholder is authenticated by demonstrating
PIV card without the holder’s active control of the PIV authentication private key in a
participation, and provides a low level of challenge response protocol that can be validated using
assurance 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
cardholder’s knowledge of the PIN
Q&A
Thank for your Attention!!