ICTNWK503 Install and maintain valid

authentication processes
ICTNWK503 Install and maintain valid authentication
processes

Determine authentication
requirements

Configure authentication
software or tools

Apply authentication
methods

Monitor authentication
system
User Authentication Overview
 User Authentication
• Fundamental security building block
• basis of access control & user accountability
• The process of verifying an identity claimed by or for a system entity
• Two steps:
• identification: specify identifier
• verification: bind entity (person) and identifier
• Distinct from message authentication (when communicating parties are
concerned with the integrity of the exchanges messages)
A model for electronic user authentication

• NIST SP 800-63-2 defines EUA as: the process of establishing

confidence in user identity that are electronically presented
• The NIST SP 800-63-2 model
• User applies to registration authority (RA) and becomes a subscriber of a
credential service provider (CSP)
• RA is a trusted entity
• The CSP exchanges with the subscriber
• The credential (a data structure) binds an identity to a token possessed by
the subscriber
• Claimant: the party to be authenticated
• Verifier: the party verifying
• The verifier passes an assertion about the subscriber to the relaying party
(PR)
A model for electronic user authentication
 Means of user authentication
• Four means of authenticating user's identity
• Based one something the individual
• knows, e.g. password, PIN
• possesses, e.g. key, token, smartcard
• is (static biometrics), e.g. fingerprint, retina
• does (dynamic biometrics), e.g. voice, sign
• Can use alone or combined
• All can provide user authentication
• All have issues
Risk assessment for user authentication

• Assurance level: the degree of certainty that a user has presented a

credential that refers to his/her identity
• Level 1: little confidence (an online forum)
• Level 2: some confidence (professional organizations)
• Level 3: High confidence (patent office applicants)
• Level 4: Very high confidence (employees accessing restricted/sensitive
services)
• Potential impact: low, moderate, impact
Risk assessment for user authentication

Assurance Level Impact Profiles

Potential Impact Categories for Authentication Errors 1 2 3 4

Inconvenience, distress, or damage to standing or reputation Low Mod Mod High

Financial loss or organization liability Low Mod Mod High

Harm to organization programs or interests None Low Mod High

Unauthorized release of sensitive information None Low Mod High

Mod/
Personal safety None None Low
High

Civil or criminal violations None Low Mod High

Password authentication

• Widely used user authentication method

• user provides name/login and password
• system compares password with that saved for specified login
• Authenticates ID of user logging and
• that the user is authorized to access system
• determines the user’s privileges
• is used in discretionary access control
 Password vulnerabilities
• offline dictionary attack
• specific account attack (user john)
• popular password attack (against a wide range of IDs)
• password guessing against single user (w/ previous knowledge about the
user)
• workstation hijacking
• exploiting user mistakes
• exploiting multiple password use
• electronic monitoring
Countermeasures for password vulnerability

• stop unauthorized access to password file

• intrusion detection measures
• account lockout mechanisms
• policies against using common passwords but rather hard to guess
passwords
• training & enforcement of policies
• automatic workstation logout
• encrypted network links
Countermeasures for password vulnerability

• It is worthwhile to study/research password and password

vulnerabilities
• Most common
• Still the most efficient
Use of hashed
passwords
Why a salt value?

• Prevents duplicate passwords from being visible in the password file

• Increases the difficulty of offline dictionary attacks
• Nearly impossible to tell if a person used the same password on
multiple systems
 UNIX Implementation
• Original scheme
• 8 character password form 56-bit key
• 12-bit salt used to modify DES encryption into a one-way hash function
• output translated to 11 character sequence
• Now regarded as woefully insecure
• e.g. supercomputer, 50 million tests, 80 min
• Sometimes still used for compatibility
 Improved implementations
• Have other, stronger, hash/salt variants
• Many systems now use MD5
• with 48-bit salt
• password length is unlimited
• is hashed with 1000 times inner loop
• produces 128-bit hash
• OpenBSD uses Blowfish block cipher based and hash algorithm called
Bcrypt
• uses 128-bit salt to create 192-bit hash value
 Password Cracking
• Dictionary attacks
• try each word then obvious variants in large dictionary against hash in password
file
• Rainbow table attacks
• a large dict of possible passwords
• for each password:
• precompute tables of hash values for all salts
• a mammoth table of hash values: e.g. 1.4GB table cracks 99.9% of alphanumeric Windows
passwords in 13.8 secs
• not feasible if larger salt values used
 Password choices/concerns
• users may pick short passwords
• e.g. 3% were 3 chars or less, easily guessed
• system can reject choices that are too short
• users may pick guessable passwords
• so crackers use lists of likely passwords
• e.g. one study of 14000 encrypted passwords guessed nearly 1/4 of them
• would take about 1 hour on fastest systems to compute all variants, and only need 1
break!
Another case study

• An analysis of passwords used by 25,000 students

• Over 10% recovered after 10^10 guesses
 Password File Access Control
• Can block offline guessing attacks by denying access to encrypted
passwords
• make available only to privileged users
• often using a separate shadow password (for su only)
• Still have vulnerabilities
• exploit O/S bug
• accident with permissions making it readable
• users with same password on other systems
• access from unprotected backup media
• sniff passwords in unprotected network traffic
Using Better Passwords

• Clearly have problems with passwords

• Goal to eliminate guessable passwords
• Still easy for user to remember
• Techniques
• user education
• computer-generated passwords
• reactive password checking (periodic checking)
• proactive password checking (at the time of selection)
 Proactive Password Checking
• Rule enforcement plus user advice, e.g.
• 8+ chars, upper/lower/numeric/punctuation
• may not suffice
• Password cracker
• list of bad passwords
• time and space issues
• Markov Model
• generates guessable passwords
• hence reject any password it might generate
• Bloom Filter
• use to build table based on dictionary using hashes
• check desired password against this table
Token-based authentication

•Object user possesses to authenticate, e.g.

• memory card (magnetic stripe)
• smartcard
 Memory Card
• store but do not process data
• magnetic stripe card, e.g. bank card
• electronic memory card
• used alone for physical access (e.g., hotel rooms)
• some with password/PIN (e.g., ATMs)
• Drawbacks of memory cards include:
• need special reader
• loss of token issues
• user dissatisfaction (OK for ATM, not OK for computer access)
Smartcard
• credit-card like
• has own processor, memory, I/O ports
• ROM, EEPROM, RAM memory
• executes protocol to authenticate with reader/computer
• static: similar to memory cards
• dynamic: passwords created every minute; entered manually by user or
electronically
• challenge-response: computer creates a random number; smart card provides its
hash (similar to PK)
• also have USB dongles
Electronic identify cards

• An important application of smart cards

• A national e-identity (eID)
• Serves the same purpose as other national ID cards (e.g., a driver’s
licence)
• Can provide stronger proof of identity
• A German card
• Personal data, Document number, Card access number (six digit random number),
Machine readable zone (MRZ): the password
• Uses: ePass (government use), eID (general use), eSign (can have private key and
certificate)
User authentication with eID
 Biometric authentication
• Authenticate user based on one of their physical characteristics:
• facial
• fingerprint
• hand geometry
• retina pattern
• iris
• signature
• voice
Operation of a
biometric
system

Verification is analogous to
user login via a smart card
and a PIN

Identification is biometric info

but no IDs; system compares
with stored templates
 Biometric Accuracy
• The system generates a matching score (a number) that quantifies
similarity between the input and the stored template
• Concerns: sensor noise and detection inaccuracy
• Problems of false match/false non-match
Remote User Authentication

• Authentication over network more complex

• Problems of eavesdropping, replay
• Generally use challenge-response
• user sends identity
• host responds with random number r
• user computes f(r,h(P)) and sends back
• host compares value from user with own computed value, if match user
authenticated
• Protects against a number of attacks
 Protocol for a password verification
• Similar approach for token
and biometric verification
Authentication Security Issues

• Client attacks: attacker attempts to achieve user authentication without

access to the remote host
• Masquerade as a legitimate user (e.g., guess the password or try all passwords)
• Countermeasure: strong passwords; limit number of attempts
Authentication Security Issues

• Host attacks: attacker attacks the host where passwords/passcodes are

stored
• Countermeasure: hashing, protect password databases
Authentication Security Issues

• Eavesdropping: attacker attempts to learn passwords by observing the

user, finding written passwords, keylogging
• Countermeasures
• diligence to keep passwords
• multifactor authentication
• admin revoke compromised passwords
Authentication Security Issues

• Replay: attacker repeats a previously captured user response

• Countermeasure
• Challenge-response
• 1-time passcodes
Authentication Security Issues

• eavesdropping
• replay
• trojan horse
Authentication Security Issues

• Trojan horse: an application or physical device masquerades as an

authentic application or device
• Countermeasure: authentication of the client within a trusted security
environment
• Denial of service: attacker attempts to disable a user authentication
service (via flooding)
• Countermeasure: a multifactor authentication with a token
Practical Application
Authentication Options
 Outline
• User authentication
• Password authentication, salt
• Challenge-response authentication protocols
• Biometrics
• Token-based authentication
• Authentication in distributed systems (multi service providers/domains)
• Single sign-on, Microsoft Passport
• Trusted Intermediaries
Password authentication

• Basic idea
• User has a secret password
• System checks password to authenticate user
• Issues
• How is password stored?
• How does system check password?
• How easy is it to guess a password?
• Difficult to keep password file secret, so best if it is hard to guess password even if you
have the password file
Basic password scheme

User Password file

kiwifruit
exrygbzyf
kgnosfix
hash function ggjoklbsz
…
…
Basic password scheme

• Hash function h : strings → strings

• Given h(password), hard to find password
• No known algorithm better than trial and error
• User password stored as h(password)
• When user enters password
• System computes h(password)
• Compares with entry in password file
• No passwords stored on disk
Unix password system

• Hash function is 25xDES

• 25 rounds of DES-variant encryptions
• Any user can try “dictionary attack”

• “Salt” makes dictionary attack harder

 Salt
•Password line
walt:fURfuu4.4hY0U:129:129:Belgers:/home/walt:/bin/csh

Compare
Salt
Input
Constant, Key
Ciphertext
A 64-bit block of 0 25x DES
Plaintext

When password is set, salt is chosen randomly

12-bit salt slows dictionary attack by factor of 212
 Dictionary Attack – some numbers
• Typical password dictionary
• 1,000,000 entries of common passwords
• people's names, common pet names, and ordinary words.
• Suppose you generate and analyze 10 guesses per second
• This may be reasonable for a web site; offline is much faster
• Dictionary attack in at most 100,000 seconds = 28 hours, or 14 hours on average
• If passwords were random
• Assume six-character password
• Upper- and lowercase letters, digits, 32 punctuation characters
• 689,869,781,056 password combinations.
• Exhaustive search requires 1,093 years on average
 Outline
• User authentication
• Password authentication, salt
• Challenge-response authentication protocols
• Biometrics
• Token-based authentication
• Authentication in distributed systems (multi service providers/domains)
• Single sign-on, Microsoft Passport
• Trusted Intermediaries
Challenge-response Authentication
Goal: Bob wants Alice to “prove” her identity to him

Protocol ap1.0: Alice says “I am Alice”

“I am Alice”
Failure scenario??
Authentication

Goal: Bob wants Alice to “prove” her identity to him

Protocol ap1.0: Alice says “I am Alice”

in a network,
Bob can not “see”
Alice, so Trudy simply
“I am Alice” declares
herself to be Alice
Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Alice’s
IP address
“I am Alice”

Failure scenario??
Authentication: another try
Protocol ap2.0: Alice says “I am Alice” in an IP packet
containing her source IP address

Trudy can create

a packet
Alice’s
“spoofing”
IP address
“I am Alice” Alice’s address
Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr
Authentication: another try
Protocol ap3.0: Alice says “I am Alice” and sends her
secret password to “prove” it.

Alice’s Alice’s
“I’m Alice”
IP addr password
playback attack: Trudy
Alice’s records Alice’s packet
OK
IP addr and later
plays it back to Bob

Alice’s Alice’s
“I’m Alice”
IP addr password
Authentication: yet another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

Alice’s encrypted
“I’m Alice”
IP addr password

Alice’s Failure scenario??

OK
IP addr
Authentication: another try
Protocol ap3.1: Alice says “I am Alice” and sends her
encrypted secret password to “prove” it.

Alice’s encryppted
IP addr password
“I’m Alice” record
and
Alice’s
OK playback
IP addr
still works!

Alice’s encrypted
“I’m Alice”
IP addr password
 Authentication: yet another try
Goal: avoid playback attack
Nonce: number (R) used only once –in-a-lifetime
ap4.0: to prove Alice “live”, Bob sends Alice nonce, R. Alice
must return R, encrypted with shared secret key

“I am Alice”

R
KA-B(R) Alice is live, and
only Alice knows
key to encrypt
nonce, so it must
Failures, drawbacks? be Alice!
Authentication: ap5.0
ap4.0 doesn’t protect against server database reading
• can we authenticate using public key techniques?
ap5.0: use nonce, public key cryptography

“I am Alice”
Bob computes
R + -
- KA(KA (R)) = R
K A (R) and knows only Alice
could have the private
key, that encrypted R
such that
+ -
K (K (R)) = R
A A
 Outline
• User authentication
• Password authentication, salt
• Challenge-response authentication protocols
• Biometrics
• Token-based authentication
• Authentication in distributed systems (multi service providers/domains)
• Single sign-on, Microsoft Passport
• Trusted Intermediaries
 Biometrics
• Use a person’s physical characteristics
• fingerprint, voice, face, keyboard timing, …
• Advantages
• Cannot be disclosed, lost, forgotten
• Disadvantages
• Cost, installation, maintenance
• Reliability of comparison algorithms
• False positive: Allow access to unauthorized person
• False negative: Disallow access to authorized person
• Privacy?
• If forged, how do you revoke?
Biometrics

• Common uses
• Specialized situations, physical security
• Combine
• Multiple biometrics
• Biometric and PIN
• Biometric and token
 Physical Biometrics
• Fingerprint • Smell
• Iris • Thermal Face
• Hand Geometry • Hand Vein
• Finger Geometry • Nail Bed
• Face Geometry • DNA
• Ear Shape
• Palm Print
• Retina
Behavioral Biometrics

• Signature
• Voice
• Keystroke
• Gait
Token-based Authentication
Smart Card
• With embedded CPU and memory
• Carries conversation w/ a small card reader
• Various forms
• PIN protected memory card
• Enter PIN to get the password
• Cryptographic challenge/response cards
• Computer create a random challenge
• Enter PIN to encrypt/decrypt the challenge w/ the card
eToken

• May store credentials

such as passwords,
digital signatures and
certificates, and private
keys
• Can offer on-board
authentication and
digital signing
Smart cards

• Size of a credit card

• Usually an embedded microprocessor with computational and
storage capabilities
• Programmable platforms:
• C/C++
• Visual Basic
• Java
• .Net (beta)
 Smart Cards cont’d
• Contact vs. contactless
• Memory vs. microprocessor
RFID

• RFID - Radio Frequency IDentification

• Integrated circuit(s) with an antenna that can
respond to an RF signal with identity information
• No power supply necessary—IC uses the RF signal
to power itself
• Susceptible to replay attacks and theft
• Examples:
• Smart Tag, EZPass
• Garage parking permits
RFID
• 13.56Mhz read/write
support
• May communicate with a
variety of transponders
(ISO15693, ISO14443
Type A & B, TagIt, Icode,
etc.)
• Reader is controlled via
PCMCIA interface using
an ASCII protocol
 Smart Card Example
Initial data (PIN)

Time Challenge Time

function

• Some complications
• Initial data (PIN) shared with server
• Need to set this up securely
• Shared database for many sites
• Clock skew
Fingerprints

• Vast amount of data available on fingerprint pattern matching

• Data originally from forensics
• Over 100 years of data to draw on
• Thus far all prints obtained have been unique
Fingerprint Basics

• Global features
• Features that can be seen with the naked eye
• Basic ridge patterns
• Local features
• Minutia points
• Tiny unique characteristics of fingerprint ridges used for positive
identification
 Basic Ridge Patterns

• Loop
• 65% of all
fingerprints

• Arch
• Plain and tented
arch

• Whorl
• 30% of all
fingerprints
• One complete
circle
Local Features

• Also known as minutia points

• Used for positive identification
• Two or more individuals may have the same global features, but
different minutia
• Minutia points do not have to be inside the pattern area
Types of Minutia

• Ridge ending
• Ridge bifurcation
• Ridge divergence
• Dot or island – ridge so short it appears to be a dot
• Enclosure – ridge separates and then reunites around an area of
ridge-less skin
• Short ridge – bigger than a dot
Minutia Characteristics

• Orientation
• The direction the minutia is facing
• Spatial frequency
• How far apart the ridges are around the point
• Curvature
• Rate of change of orientation
• Position
• X,Y location relative to some fixed points
Algorithms

• Image-based
• Pattern-based
• Minutia-based
 Fingerprint Scanners

Digital Persona U.are.U Pro HP IPAQ IBM Thinkpad T42

Biometric Authentication Terms

• False Acceptance Rate (FAR)

• False Match Rate (FMR)
• Percentage of access attempts by unauthorized
individuals which are nevertheless successful
• False Rejection Rate (FRR)
• False Non-Match Rate (FNMR)
• Percentage of access attempts by enrolled individuals
who are nevertheless rejected
• Equal Error Rate
• FAR = FRR
 Outline
• User authentication
• Password authentication, salt
• Challenge-Response
• Biometrics
• Token-based authentication
• Authentication in distributed systems
• Single sign-on, Microsoft Passport
• Trusted Intermediaries
Single sign-on systems e.g. Securant, Netegrity,

LAN

Rules Database

user name,
Authenticati
password, Application
other auth on

Server

• Advantages
– User signs on once
– No need for authentication at multiple sites, applications
– Can set central authorization policy for the enterprise
 Microsoft Passport
• Launched 1999
• Claim > 200 million accounts in 2002
• Over 3.5 billion authentications each month
• Log in to many websites using one account
• Used by MS services Hotmail, MSN Messenger or MSN subscriptions; also Radio
Shack, etc.
• Hotmail or MSN users automatically have Microsoft Passport accounts set up
Passport log-in
 Trusted Intermediaries
Symmetric key problem: Public key problem:
• How do two entities establish • When Alice obtains Bob’s
shared secret key over network? public key (from web site, e-
Solution: mail, diskette), how does she
know it is Bob’s public key,
• trusted key distribution center
not Trudy’s?
(KDC) acting as intermediary
between entities Solution:
• trusted certification
authority (CA)
Key Distribution Center (KDC)
• Alice, Bob need shared symmetric key.
• KDC: server shares different secret key with each registered
user (many users)
• Alice, Bob know own symmetric keys, KA-KDC KB-KDC , for
communicating with KDC.

KDC
KA-KDC KP-KDC
KX-KDC
KP-KDC KB-KDC
KY-KDC

KZ-KDC
KA-KDC KB-KDC
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?

Alice and Bob communicate: using R1 as

session key for shared symmetric encryption
 Ticket and Standard Using KDC
• Ticket
• In KA-KDC(R1, KB-KDC(A,R1) ), the KB-KDC(A,R1) is also known as a ticket
• Comes with expiration time
• KDC used in Kerberos: standard for shared key based authentication
• Users register passwords
• Shared key derived from the password
 Kerberos
• Trusted key server system from MIT
• one of the best known and most widely implemented trusted third party key distribution
systems.
• Provides centralised private-key third-party authentication in a distributed
network
• allows users access to services distributed through network
• without needing to trust all workstations
• rather all trust a central authentication server
• Two versions in use: 4 & 5
• Widely used
• Red Hat 7.2 and Windows Server 2003 or higher
Kerberos 4 Overview
Kerberos Realms

• A Kerberos environment consists of:

• a Kerberos server
• a number of clients, all registered with server
• application servers, sharing keys with server
• This is termed a realm
• typically a single administrative domain
• If have multiple realms, their Kerberos servers must share keys and
trust
 When NOT Use Kerberos
• No quick solution exists for migrating user passwords from a standard UNIX
password database to a Kerberos password database
• such as /etc/passwd or /etc/shadow
• For an application to use Kerberos, its source must be modified to make the
appropriate calls into the Kerberos libraries
• Kerberos assumes that you are using trusted hosts on an untrusted network
• All-or-nothing proposition
• If any services that transmit plaintext passwords remain in use, passwords can still be
compromised
Certification Authorities
• Certification authority (CA): binds public key to particular
entity, E.
• E (person, router) registers its public key with CA.
• E provides “proof of identity” to CA.
• CA creates certificate binding E to its public key.
• Certificate containing E’s public key digitally signed by CA – CA says
“this is E’s public key”

Bob’s digital
+
public +
signature KB
key KB (encrypt)
CA
certificate for
K-
Bob’s private
identifying key CA Bob’s public key,
information signed by CA
 Certification Authorities
• When Alice wants Bob’s public key:
• gets Bob’s certificate (Bob or elsewhere).
• apply CA’s public key to Bob’s certificate, get Bob’s public key
• CA is heart of the X.509 standard used extensively in
• SSL (Secure Socket Layer), S/MIME (Secure/Multiple Purpose Internet Mail
Extension), and IP Sec, etc.

+ digital Bob’s
KB signature public
+
(decrypt) KB key

CA
public +
K CA
key
 Single KDC/CA

• Problems
• Single administration trusted by all principals
• Single point of failure
• Scalability
• Solutions: break into multiple domains
• Each domain has a trusted administration
 Multiple KDC/CA Domains
Secret keys:
• KDCs share pairwise key
• topology of KDC: tree with shortcuts
Public keys:
• cross-certification of CAs
• example: Alice with CAA, Boris with CAB
• Alice gets CAB’s certificate (public key p1), signed by CAA
• Alice gets Boris’ certificate (its public key p2), signed by CAB (p1)
Key Distribution Center (KDC)
Q: How does KDC allow Bob, Alice to determine shared
symmetric secret key to communicate with each other?

KDC
generates
KA-KDC(A,B) R1

Alice KA-KDC(R1, KB-KDC(A,R1) )

Bob knows to
knows use R1 to
R1 KB-KDC(A,R1) communicate
with Alice

Alice and Bob communicate: using R1 as

session key for shared symmetric encryption
Consider the KDC and CA servers.
Suppose a KDC goes down. What is the
impact on the ability of parties to
communicate securely; that is, who can
and cannot communicate? Justify your
answer. Suppose now a CA goes down.
What is the impact of this failure?
Authentication Token Formats

• A security token (authentication token) is a representation of

security-related data (not to be confused with an e-Token)
• Examples:
• X.509 certificates
• Kerberos tickets
• Custom security tokens
X.509 Certificates

• Use of digital certificates issued by a trusted Certificate

Authority (e.g. VeriSign)
• A Digital Certificate contains information to assert an
identity claim
• Name
• Serial number
• Expiration dates
• Certificate holder’s public key (used for encrypting/decrypting
messages and digital signatures)
• Digital signature of Certificate Authority (so recipient knows that the
certificate is valid)
• The recipient may confirm the identity of the sender with
the Certificate Authority
Kerberos Tickets

• Clients share secret symmetric key with server

• Clients login to authentication server
• Server returns a Ticket-Granting Ticket (TGT) encrypted with
client’s key
• Client sends decrypted TGT to Ticket Granting Service
• TGS sends ticket authorizing network access and certain
services
• Session ticket data:
• Name
• Network address
• Time stamp
• Expiration dates
• Session key
Custom Security Tokens

• May contain additional context information:

• Access method
• wired, local terminal
• wired remote terminal
• wireless PDA
• Authentication method
• Password
• e-Token
• Fingerprint
• Trust level
 Trust Level Extension
• Different trust levels for devices with different levels of implementation
reliability
• Still very abstract and should be further developed
• definition
• representation
• storage
• exchange
• verification
• translation across trust domains
Example Authentication (Security)
Token Request
<AuthenticationToken>
<CreatedAt>08/03/2004 8:00:00 AM</CreatedAt>
<ExpiresAt>08/03/2004 5:00:00 PM</ExpiresAt>
<Username>Weaver</Username>
<KeyStr>FINGERPRINT_KEY_STRING</KeyStr>
<Technology>Fingerprint</Technology>
</AuthenticationToken>
 Example Authentication (Security)
Token Reply
<TrustLevelSecToken>
<CreatedAt>08/03/2004 8:00:00 AM</CreatedAt>
<ExpiresAt>08/03/2004 5:00:00 PM</ExpiresAt>
<UserID>5323</UserID>
<TrustLevel>Fingerprint</TrustLevel>
<TokenIssuer>http://cs.virginia.edu/TrustSTS.asmx</TokenIssuer>
<TrustAuthority>http://cs.virginia.edu/TrustAuthority.asmx</TrustAuthority>
</TrustLevelSecToken>
Authentication (Online Video, 14 minutes)

109
110
Authentication (Online Video, 50 minutes)

111
112
Kerberos (Online Video, 22 minutes)

113
114
Application Example
Next Generation
Two Factor Authentication
21st Century Remote Access

• Laptop

• Home / Other Business PC

• Hotel / Cyber Café / Airport

• Smart Phone / Blackberry

Who is using your VPN
Problems With Passwords
• “Social engineering”
• Finding written password
– Post-It Notes
• Guessing password / pin
– Dog/Kid’s name/ Birthday
• Shoulder surfing
• Keystroke logging
– Can be resolved with mouse based entry
• Screen scraping (with Keystroke logging)
• Brute force password crackers
– L0phtcrack
Two Factor Authentication

• Something you know

• Pin
• Password
• Mothers Maiden Name
• Something you own
• Keys
• Credit Card
• Token
• Phone
• Something you are
• Fingerprint
• DNA
• Two Factor Authentication is Two of the above
• Example: ATM Cash Machine
• Something you Know – Pin
• Something you Own - Cash Card (Chip)
Existing Form Factors

Smartcards / USB Tokens

• End user must remember to carry the card!

• Smartcards need readers

• Both need software drivers

• Remote Users can’t use other PC’s or Cybercafés

• Smart phones, Blackberry’s, PocketPC etc are limited by size

• Requires certificate enrolment and replacement

• Deployment - Remote users must be sent a hardware device

• Support – Pin Management & Failed token must be managed

Existing Form Factors

Hardware Tokens
• End user must remember to carry the token!
• Deployment - Remote users must be sent a hardware device
• Token may require resynchronisation
• Support – Pin Management & Failed token must be managed
• Short Term Contractors - Don’t always return the token
• B2B – One to many companies requires many identical tokens
The Next Generation

Mobile Phone based Authentication

Mobile Phones solve all the previous issues however

• Adding Software to a range of Phones is difficult to

support

• SMS at peak times sometimes cause delay of several

minutes
Pre-Load vs. On demand SMS

123
 The SecurEnvoy Approach

The first 6 digit passcode is sent at enrolment

One Time Code

Each authentication (good or bad) send’s the next required code

Passcode
Passcode
Each Code can only be used once

573921
347865
198462

Day Code
Each day (or set number of days) a new code is sent if used
If the current day code hasn’t been used, it’s still secret and
will
not require updating
Each day code can be reused for the current and following
day Tmp Code
A pre-agreed static code that automatically switches back to
One Time or Day Code after a set number of days

10 failed attempts in a row disables account and

SMS messages (all modes)
PIN Management
Traditional Approach
UserID: fred
PIN: 3687
Passcode:435891
Microsoft Password: P0stcode

Two Factor Authentication requires something you know &

something you own
Why authenticate with two things you know?

The SecurEnvoy Approach

UserID: fred
Microsoft Password: P0stcode
Passcode: 435891

Reuse The Microsoft or other LDAP Password as the PIN

Easier end user authentication experience
No PIN Administration required
Can also support a PIN if required
Ease Of Use (Cost) Vs Risk

Cost Vs Risk
Expensive / Hard Tokens /
Smartcards
Cost / Use

SecurEnvoy SecurEnvoy
SecurEnvoy
1 Day Code One Time Code
7 Day Code
30 Day
Password
Fixed
Cheap Password
Easy
High Risk Risk Low Risk
Standard Authentication Solutions
SecurEnvoy Solution
Re-enter user information

SQL LDAP Sync Active

Database Directory
Use AD or other
Replication LDAP as the
database
SQL
Database
No schema change required
Data Encrypted with 128 bit AES
SecurAccess Authentication

SecurAccess Authentication

Andyk
Passcode
Something You Know
P0stcode
573921

234836 Something You Own

Enter 6 Digit Number from Mobile Phone

Summary

The Next Generation is Mobile Phone Based Authentication

Up to 60% cheaper that Hardware Tokens

No Software on the phone

Must Allow for SMS Delays & Loss of Signal

Must Be Easy To Use (6 Digit Display On Phone)

Should Re-Use Existing Passwords (Windows) as the PIN

Should Use LDAP as the Database

www.SecurEnvoy.com
Implementing an EIGRP-Based
Solution
Implementing and Verifying EIGRP Authentication
Router Authentication

• Implement security to the routing protocol by supporting

authentication
• A router authenticates the source of each routing update packet that
it receives.
• Prevent false routing updates from updating the routing table:
• Prevent deliberate false routing updates sourced by unapproved sources
• Ignore malicious updates, thus preventing them from disrupting the
routing or taking down the adjacency
Router Authentication (Cont.)

• Many routing protocols support authentication

• Simple password authentication is supported by:
• OSPF
• RIPv2
• MD5 authentication is supported by:
• EIGRP
• OSPF
• RIPv2
• BGP
Simple Password vs. MD5 Authentication

• Simple password authentication:

• The router sends a packet and a key.
• The neighbor checks if the key matches its key.
• The process is not secure.
• MD5 authentication:
• This authentication is secure, as described in RFC1321.
• This authentication does not include confidentiality (content not encrypted).
• The router generates a message digest.
• The message digest is sent with the packet.
• The key is not sent.
MD5 Authentication for EIGRP

• EIGRP supports MD5 authentication.

• The router generates a MD5 message digest.
• Multiple keys can be configured in all EIGRP routers.
• The receiving router computes the MD5 hash from the received EIGRP
information.
• Time should be synchronized between all routers, and NTP can be used.
Key Chain

• EIGRP allows keys to be managed

using key chains
• A key chain is a set of keys
associated with an interface.
• Includes key IDs, keys, and key
lifetimes
• The first valid activated key is used
in the outgoing direction.
• Incoming packets are checked
against all valid keys.
Planning for EIGRP Authentication

• Examine the existing EIGRP configuration

• Define the authentication type
• Define how many keys will be used
• Define if an optional lifetime parameter will be used
Requirements for EIGRP Authentication

• EIGRP AS number
• Authentication mode
• One or more keys
• Key lifetimes (optional)
Steps to Configure EIGRP MD5 Authentication

• Configure the authentication mode for EIGRP

• Configure the key chain
• Configure the lifetime of each key in the key chain
• Enable authentication to use the key or keys in the key chain
 Configure Authentication Mode
R1(config)#
interface Serial0/0/1
ip authentication mode eigrp 110 md5 md5
R2(config)#
interface Serial0/0/1
ip authentication mode eigrp 110 md5 110 md5
• Specify the type of authentication used in EIGRP packets for router R1 and R2
 Configure the Key Chain
R1(config)# R2(config)#
key chain routerR1chain key chain routerR2chain
key 1 key 1
key-string firstkey key-string firstkey
key 2 key 2
key-string secondkey key-string secondkey

• Create the key-chain to enter key chain key configuration mode.

• Create an authentication key on a key chain.
• Define the authentication string for a key (password).
 Configure the Lifetime of The Key or Keys
R1(config)#
key chain routerR1chain
key 1
key-string firstkey
accept-lifetime 04:00:00 Jan 1 2009 infinite
send-lifetime 04:00:00 Jan 1 2009 04:00:00 Jan 31 2009
key 2
key-string secondkey
accept-lifetime 04:00:00 Jan 25 2009 infinite
send-lifetime 04:00:00 Jan 25 2009 infinite

• If you wish, you can define when the key will be accepted or sent.
 Enable Authentication of EIGRP Packets
R1(config)#
interface Serial0/0/1
ip authentication key-chain eigrp 110 routerR1chain
R2(config)#
interface Serial0/0/1
ip authentication key-chain eigrp 110 routerR2chain
• Enable authentication of EIGRP packets using the key or keys in the key chains
routerR1chain and routerR2chain on routers R1 and R2, respectively.
Router R1 Configuration for MD5
Authentication
R1#
<output omitted>
key chain routerR1chain
key 1
key-string firstkey
accept-lifetime 04:00:00 Jan 1 2009 infinite
send-lifetime 04:00:00 Jan 1 2009 04:00:00 Jan 31 2009
key 2
key-string secondkey
accept-lifetime 04:00:00 Jan 25 2009 infinite
send-lifetime 04:00:00 Jan 25 2009 infinite
<output omitted>
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
!
interface Serial0/0/1
bandwidth 256
ip address 192.168.1.101 255.255.255.224
ip authentication mode eigrp 110 md5
ip authentication key-chain eigrp 110 routerR1chain
!
router eigrp 110
network 172.16.1.0 0.0.0.255
network 192.168.1.0
auto-summary
 Verifying MD5 Authentication for EIGRP
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 110
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 192.168.1.102 Se0/0/1 12 00:03:10 17 2280 0 14

• Verify that the EIGRP neighbor relationship is up

R1#show ip route
<output omitted>
Gateway of last resort is not set
D 172.17.0.0/16 [90/40514560] via 192.168.1.102, 00:02:22, Serial0/0/1
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:31:31, Null0
C 172.16.1.0/24 is directly connected, FastEthernet0/0
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.96/27 is directly connected, Serial0/0/1
D • Verify that the IP routing
192.168.1.0/24 table is populated
is a summary, 00:31:31, Null0
 Verifying MD5 Authentication for EIGRP
(Cont.)
R1#show key chain
Key-chain routerR1chain:
key 1 -- text “firstkey"
accept lifetime (04:00:00 Jan 1 2009) - (always valid) [valid now]
send lifetime (04:00:00 Jan 1 2009) - (04:00:00 Jan 31 2009)
key 2 -- text “secondkey"
accept lifetime (04:00:00 Jan 25 2009) - (always valid) [valid now]
send lifetime (04:00:00 Jan 25 2009) - (always valid) [valid now]

• Verify the key chains and keys

• This output of the show key chain command is from January 27, 2009.
 Verifying MD5 Authentication for EIGRP
(Cont.)
R1#debug eigrp packet
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
*Jan 21 16:38:51.745: EIGRP: received packet with MD5 authentication, key id = 1
*Jan 21 16:38:51.745: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.102
*Jan 21 16:38:51.745: AS 110, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 pe
erQ un/rely 0/0

R2#debug eigrp packet

EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
R2#
*Jan 21 16:38:38.321: EIGRP: received packet with MD5 authentication, key id = 1
*Jan 21 16:38:38.321: EIGRP: Received HELLO on Serial0/0/1 nbr 192.168.1.101
*Jan 21 16:38:38.321: AS 110, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 pe
erQ un/rely 0/0

• Use debug to verify the operation

 Misconfigured Key
R1#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
R1#
*Jan 31 23:20:21.967: EIGRP: Sending HELLO on Serial1/0
*Jan 31 23:20:21.967: AS 110, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0
*Jan 31 23:20:22.315: EIGRP: pkt key id = 2, authentication mismatch
*Jan 31 23:20:22.315: EIGRP: Serial1/0: ignored packet from 192.168.1.102, opcod
e = 5 (invalid authentication)

• The MD5 authentication key is different for routers R1 and R2.

•
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 110
• The EIGRP neighbor relationship is down.
Summary

• There are two types of router authentication: simple password and MD5
authentication.
• When EIGRP authentication is configured, the router generates and checks
every EIGRP packet and authenticates the source of each routing update
packet that it receives. EIGRP supports MD5 authentication.
• To configure MD5 authentication, use the ip authentication mode eigrp and
ip authentication key-chain interface commands. The key chain must also be
configured to define the keys.
• Use show ip eigrp neighbors, show ip route, and debug eigrp packets to
verify MD5 authentication.
Questions