each party shares own master key with KDC ... forwards thi - PowerPoint PPT Presentation


PPT – each party shares own master key with KDC ... forwards thi PowerPoint presentation | free to download - id: 29755-NmRkY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

each party shares own master key with KDC ... forwards thi


each party shares own master key with KDC ... forwards this ticket to Bob ... to limit impersonation, list transited domains in ticket ... – PowerPoint PPT presentation

Number of Views:121
Avg rating:3.0/5.0
Slides: 47
Provided by: TheL76
Tags: kdc | each | forwards | key | master | party | shares | thi | ticket


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: each party shares own master key with KDC ... forwards thi

Lecture 4 Authentication
  • Anish Arora
  • CSE5473
  • Introduction to Network Security

  • Password based schemes
  • EKE
  • Secure Shell (SSH)
  • Address based schemes
  • TCP, subject to syn attacks
  • Key based schemes
  • Lamport Hash
  • Needham Schroeder and Dennis AS
  • Kerberos, an old system

Password-based authentication
  • Proof by knowledge sharing
  • convenient for dealing with people (unaided by
    smart end devices)
  • but approach is risky when applied to machine
    authentication e.g., cellular phone password
    communications subject to cloning
  • mechanisms needed to support single password
    across multiple hosts and resources
  • key problem in network context eavesdropping
  • on the wire or at entry
  • by reading files where passwords are stored
  • by guessing online (even with limitations on
    number of tries)
  • by performing offline searches

Password guessing
  • Passwords are easily guessed
  • 123456
  • names of family members, initials
  • secret
  • stress related words (deadline, work)
  • sports teams or terms
  • payday, bonkers
  • current season
  • ethnic group
  • repeated characters
  • obscenities, sexual terms
  • Online to deal with this
  • limit tries (deny further access, raise alarm,
    delay subsequent access)
  • audit access history or tell users about their
    previous usage

Password guessing
  • Offline
  • storing pwd file is unsafe, so Unix approach was
    to store hash(pwd) file and make that file world
  • but this is subject to dictionary attack ?
  • capture file of hash(pwd) search whether any
    easy/wellknown pwds hash is in file
  • a technique use to mitigate the dictionary attack
    is to add salt
  • salt is a non-secret randomly chosen value per
  • store hash(pwd, salt), instead of storing
  • so users with same pwd have different stored
  • salt makes it difficult to search for some
    account whose pwd is easy, but not more difficult
    for guessing a particular users password
  • shadow file is used to store the pwd file in root
    accessible domain and x-ed out pwd file in
    public domain

Passwords as keys how to compute hashed
  • Humans prefer short, memorable key
  • (common is 8 characters, 48bits)
  • Can use directly or as basis for constructing
    longer key
  • directly as 56-bit key
  • cant use for RSA p,q
  • but can use as seed for rng
  • Unix used this approach (crypt3)
  • instead of encrypting password, used password
    based key to encrypt a well known value, with DES
  • derived 56 bit key from first 8 (7-bit ASCII)
  • encryption performed 25 times
  • brute force attack on alphanumeric password is
    (262610)8 248 , lends itself to dictionary

Password storage
  • System storage options
  • per node /etc/passwd
  • at one location authentication storage server,
    retrieved by node e.g. Yellow Pages / NIS
    (Network Information Service)
  • at facilitator node CA server
  • Authenticating node needs to
  • store hash only
  • or store table encrypted with good, protected key
  • but needs to be in non-volatile memory (e.g.,

Password-based authentication protocols
  • Send pwd, compare against hash(pwd)
  • Send hash(pwd), compare against hash(pwd)
  • Send hash(pwd), compare against hash(hash(pwd))
  • Send hash(pwd) as secret in challenge/response

Strong password protocols using passwords to
exchange keys
  • No user-specific information stored at a server,
    so someone who impersonates or eavesdrop cannot
    gain information for dictionary attack
  • Recall Diffie Helman had authentication issues
  • EKE (encrypted key exchange) jk share weak
    secret h(pwd)
  • j?k h(pwd)gxj mod p encrypt with
    h(pwd) as key
  • k?j h(pwd)gxk mod pKC1 C1 is
    challenge, K gxjxk mod p
  • j?k KC1,C2 C2 is challenge
  • k?j KC2

Strong password protocols another pasword-based
key exchange
  • SPEKE (simple password exponential key exchange)
  • jk share weak secret h(pwd)
  • j?k h(pwd)j mod p
  • k?j choose challenge C1
  • h(pwd)k mod p, C1
  • j?k choose challenge C2 K h(pwd)jk mod p
  • KC1, C2
  • k?j KC2

Secure Shell (SSH)
  • Precursor for client c to logon to server s with
    username and password in remote setting
  • also based on Diffie Helman
  • server authentication prevents client from
    divulging password
  • assumes c knows the public key of s
  • Protocol
  • c?s gxc mod p
  • c computes K gxcxs mod p
  • H hash(params gxc mod
    p gxs mod p K)
  • s?c (B.s, gxs mod p, R.s H)
  • c computes K, extracts H from
    B.sR.sH, and checks hash

Secure Shell
  • j?k h(pwd)gxj mod p encrypt with
    h(pwd) as key
  • k?j h(pwd)gxk mod pKC1 C1 is
    challenge, K gxjxk mod p
  • j?k KC1,C2 C2 is challenge
  • k?j KC2

Address-based authentication
  • Instead of sending passwords, assume identity is
    derived from the network address from where
    data arrives
  • Wrt authorization, user on remote location is
    mapped to local user, and given same privileges
  • Unix implementations of these ideas
  • per node
  • maintain equivalent machines in
    /etc/hosts.equiv file accounts on node j are the
    same as node k
  • so accounts must have same name on equivalent
    nodes get equal privileges
  • per user
  • maintain list of ltaddress of remote machine,
    account name at remote machine, local namegt
  • .rhosts file in each users home directory, same
    privileges are given as would be given to
    corresponding local account

Threats in address-based authentication
  • Address Spoofing Sending on behalf of other
    addresses is possible at data link or network
  • Such forging may be dealt with as follows
  • e.g., on a ring or a star, detection of link
    level forging is easy
  • e.g., ingress router may check whether source
    address is valid
  • by per-link configuration of routers to check
    whether source addresses are as expected, but
    this is expensive to implement
  • if all routers are trusted (!), then by
    calculating this per link information from a
    routing database

Threats in address-based authentication
  • Receiving the messages of others addresses also
  • trivial in broadcast environment
  • possible when interceptor is in the path
  • but link address checking of all possible
    messages to discard those that dont belong to
    source may be hard
  • when not in path, by injecting routing messages
    to attract source traffic
  • e.g. source routing feature of IP allow source
    to specify intermediate destinations
  • interceptor can propose itself to be on source
  • return traffic too will follow source route and
    can be received in this way

TCP-based Authentication
  • TCP not intended for use as an authentication
  • But IP address in TCP connection often used for
  • One mode of IPSec uses IP address for
  • This can cause problems
  • This material is from Mark Stamps Information
    Security book

TCP 3-way Handshake
SYN, ACK a1, SEQ b
ACK b1, data
  • Recall the TCP three way handshake
  • Initial SEQ number must be random
  • Why? See the next slide

TCP Authentication Attack
1. SYN, SEQ t (as Trudy)
2. SYN, ACK t1, SEQ b1
3. SYN, SEQ t (as Alice)
5. ACK b21, data
4. SYN, ACK t1, SEQ b2
TCP SYN Attack (contd.)
  • Trudy cannot see what server Bob sends, but she
    can send packets to Bob while posing as Alice
  • Trudy must prevent Alice from receiving Bobs
    packets (or else connection will terminate)
  • If password (or other authentication) required,
    this attack fails
  • If TCP connection is relied on for
    authentication, then attack succeeds
  • Bad idea to rely on TCP for authentication

TCP Authentication Attack
Initial SEQ numbers Mac OS X
Random SEQ numbers
  • If initial SEQ numbers not very random
  • possible to guess initial SEQ number
  • and previous attack will succeed

Key-based authentication
  • As discussed before
  • These are used to convince parties of each others
    identity and to exchange session keys
  • May be one-way or mutual
  • one-way allows sender receiver not to be in
    communication at same time, e.g. email
  • Primary issues are
  • confidentiality to protect session keys
  • timeliness to prevent replay attacks
  • May use public keys, shared keys, passwords,
    even hash functions

Replay attacks
  • where a valid signed message is copied and later
  • simple replay
  • repetition that can be logged
  • repetition that cannot be detected
  • backward replay without modification
  • countermeasures include
  • use of sequence numbers (sometimes impractical)
  • timestamps (needs synchronized clocks)
  • challenge/response (using unique nonce)

One-way authentication with Lamports hash
  • No public key cryptography
  • But still safe from eavesdropping database
    reading (on servers)
  • Useful in asymmetric environments
  • e.g. Alice is client stores pwd
  • Bob is server stores username, n,
  • The protocol
  • j?k j
  • k?j n
  • j?k hashn-1pwd
  • k compares hash of received value with its
    stored value
  • discards old value and stores decremented n
    received value

Lamports hash
  • Can use salt with hash
  • S/KEY is a deployed version of this scheme
  • Scheme is vulnerable to small n attack
  • Mal sends mltn to j, gets hashm-1(pwd) from j
  • uses this hash value to authenticate itself as to
  • Use of asymmetry to decrease processing at j
  • send list of hash(pwd), hash2(pwd),,
    hashn-1(pwd) to j, now cant fool j
    into sending earlier value
  • this idea is used in sensor networks

Login with shared secret
  • A version of one-way authentication
  • k?j str
  • j?k S.jk ltstrgt , where S can be hash
  • subject to password attack
  • compromise of database at k lets j be
  • include identity of j in response if
    protocol used in symmetric settings
  • Another version
  • k?j S.jk ltstrgt
  • j?k str , where S.jk is reversible (e.g.
  • allows off-line guessing of S
  • if str has non random part, j can
    authenticate k

Login with shared secret
  • Yet another version
  • j?k S.jk lttimestampgt
  • assumes that clocks are synchronized
  • stateless
  • replay attack ? remember messages received in
    skew window
  • must prevent the clock of k from being forced
    back ? secure network clock sync
  • replay attack ? several servers with same secret
    (so include server name)
  • can use message digest instead of encryption, so
    send timestamp in clear

One-way authentication using symmetric encryption
  • refine use of KDC but cant have final exchange
    of nonces
  • 1. j?KDC j, k, N1
  • 2. KDC?j S.j S, k, N1, S.k S, j
  • 3. j?k S.k S, j , SM
  • does not protect against replays
  • could rely on timestamp in message, though email
    delays make this problematic

One-way authentication using public-keys
  • use a digital signature with a digital
  • j?k M, R.jH(M), R.AS T, j, B.j
  • i.e., message, signature, certificate
  • can encrypt message if confidentiality a concern,
  • either via sending instead of M B.kM
  • or by using encrypted session key B.k S,

Mutual authentication using symmetric encryption
  • As discussed in Lecture 3, use a two-level
    hierarchy of keys
  • Usually with a trusted Key Distribution Center
  • each party shares own master key with KDC
  • KDC generates session keys used for connections
    between parties
  • master keys used to distribute these to them

A flaw in the original protocol
  • original version of third-party key distribution
    protocol for session between j and k mediated by
    KDC had a flaw
  • protocol
  • 1. j?KDC N1
  • 2. KDC?j S.j S, N1, S.k S, j
  • 3. j?k S.k S, j
  • 4. k?j S N2
  • 5. j?k S f(N2)

The flaw
  • Protocol is vulnerable to a replay attack if an
    old session key has been compromised
  • then message 3 can be resent convincing k that is
    communicating with j
  • modifications to address this require
  • timestamps (Denning 81)
  • using an extra nonce (Neuman 93)
  • Kerberos v.4 is based on this protocol, but with
    timestamps other main used version of Kerberos
    is v.5

Mutual authentication using public-key encryption
  • have a range of approaches based on the use of
    public-key encryption
  • need to ensure have correct public keys for other
  • using a central Authentication Server (AS)
  • various protocols exist using timestamps or

Denning AS Protocol
  • Denning 81 presented the following
  • 1. j?AS j, k
  • 2. AS?j R.AS j, B.j, T, R.AS k, B.k, T
  • 3. j?k R.AS j, B.j, T, R.AS k, B.k, T,
    B.k S, T
  • note session key is chosen by A, hence AS need
    not be trusted to protect it
  • timestamps prevent replay but require
    synchronized clocks

  • trusted key server system from MIT
  • provides centralised private-key trusted
    third-party authentication in a distributed
  • 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
  • 4 only for TCP/IP networks, greater installed
  • 5 is more complex, not just for TCP/IP networks,
    more functionality
  • implementation KDC on secure node subroutine
    library for applications (eg telnet, rtools, NFS)
    to authenticate users

Kerberos requirements
  • first published report identified its
    requirements as
  • security
  • reliability
  • transparency
  • scalability
  • implemented using an authentication protocol
    based on Needham-Schroeder

Kerberos 4 overview
  • for TCP/IP networks
  • has an Authentication Server (AS)
  • users initially negotiate with AS to identify
  • AS provides a non-corruptible authentication
    credential (ticket granting ticket TGT)
  • has a Ticket Granting server (TGS)
  • users subsequently request access to other
    services from TGS on basis of users TGT
  • symmetric keys are typically DES

Kerberos 4 overview
v4 protocol
  • j?AS j, tgs
  • AS?j Sj Sj,TGS , STGS Tj,TGS
  • j?TGS Sj,TGS Aj,k ,
    STGS Tj,TGS, k
  • TGS?j Sj,TGS Sj,k , Sk Tj,k
  • j?k Sj,k Aj,k ,
    Sk Tj,k
  • Issues
  • Mal can cache replay old authenticators, since
    servers may not store all valid tickets
  • Clocks can be fooled to correct their time, so
    replay may succeed
  • Mal can execute server program that impersonates
    Kerberos records passwords

Kerberos 4 replicas
  • login session defined as period from login to
  • principals are users and resources
  • principals share password (humans)/secret key
    (network devices) with KDC
  • KDC may be replicated
  • replicas share same master KDC key
  • have identical databases of principals secret
  • this makes coordination an issue if any one
    replica is down/slow
  • master database (whose entries are encrypted
    under KDC master key) is exchanged in clear,
    integrity via secure hash

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
  • principals are divided in realms
  • each has its own KDC database
  • if there are multiple realms, their KDCs must
    share keys and trust (although each will have a
    separate master key)
  • register each KDC as a principal of each other
    realms KDC

Kerberos realms
  • if Alice in realm A wishes to talk to Bob in
    realm B
  • Alice gets from her KDC a ticket to KDC in realm
  • KDC of realm B is registered as principal in KDC
    of realm A
  • Alice sends a tgs request to KDC of realm B along
    with her ticket
  • the source realm of Alice, A, is part of a
    principals name
  • so the KDC of B knows which key to use
  • no chaining of realms
  • otherwise principal of realm A could go via realm
    B to realm C even if A and C do not share master
  • prevents rogue AS from impersonating not just
    its own principals but every principal by
    claiming to be the penultimate KDC in a chain

Kerberos for privacy and integrity
  • encrypt and protect (with modified version of DES
  • if only integrity desired, DES CBC residue may be
    too expensive so used own algorithm for checksum
  • algorithm not documented (but not yet broken)
  • checksum is hash over session key message
  • message checksum
  • may not have weak collision freedom, may be
    reversible and so leak session key

Kerberos network layer addresses
  • TGT ticket contains Alices network layer
  • Bob checks address of connect request matches
  • Alice cant handoff ticket to Ted
  • Ted cant steal session key and use it from
  • prevent eavesdropping/replay with 5 min window
  • Issues
  • does not work with mobile nodes
  • does not support delegation
  • addresses easily spoofable

Kerberos message format
  • timestamp seconds since 1970-1-1 expires in
  • standard Unix format
  • D bit direction (used to avoid reflection
  • lifetime octet, units of 5 min (up to 21 hours,
    not enough)
  • 5 ms granularity timestamp (for quick auth.
  • session key 8 byte DES key
  • B bib byteorder (little or big endian)
  • padding, network address, message type, version

Kerberos v5
  • developed in mid 1990s
  • provides improvements over v4
  • addresses environmental shortcomings
  • fixed network protocol, fixed encryption
    algorithm, fixed byte order, short ticket
    lifetime, no delegation, no inter-realm chaining
  • addresses technical deficiencies
  • weak encryption, session keys, password attacks
  • specified as Internet standard RFC 1510

Kerberos 5 environmental improvements
  • message layout no longer fixed, uses ASN data
  • allows use of non IP networks
  • allows use of different encryption schemes
  • may delegate rights to access object, for limited
  • e.g. so Alice could log onto node Bob and then
    telnet onto Carol
  • involves exchanging TGT with one with different
    network address (including multiple/all
  • forwards this ticket to Bob
  • ticket lifetime can now be unlimited (17 bytes),
    tickets can be renewed (but only) before they
    expire, can be postdated
  • useful for long running applications
  • but cannot be revoked

Kerberos 5 realm hierarchy and chaining
  • hierarchy of realms and chaining is allowed in v5
  • in v4, each realm must be registered in source
  • now we allow Alice in realm A to impersonate any
  • to limit impersonation, list transited domains in
  • destination should reject request if any transit
    KDC is not trusted
  • transit domains are encrypted, reject request if
    final domain does not match key used to encrypt
  • realm tree policy share key with parents and
  • trust is based on allowing only shortest path
    through tree
  • to identify tree, use (IP/X.500) names in the
    domain hierarchy
  • cross links may be used as shortcuts

v5 protocol
  • j?AS j, tgs
  • AS?j Sj Sj,TGS, STGS Tj,TGS
  • j?TGS Sj,TGS Aj,k , STGS Tj,TGS
  • TGS?j Sj,TGS Sj,k , Sk Tj,k
  • j?k Sj,k Aj, , Sk Tj,k
  • optimizations
  • no longer encrypting tickets, authenticators
  • ticket target no longer in ticket
About PowerShow.com