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

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

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
Category:
Tags: kdc | each | forwards | key | master | party | shares | thi | ticket

less

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

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


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

2
Overview
  • 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

3
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

4
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

5
Password guessing
  • Offline
  • storing pwd file is unsafe, so Unix approach was
    to store hash(pwd) file and make that file world
    readable
  • 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
    user
  • store hash(pwd, salt), instead of storing
    hash(pwd)
  • so users with same pwd have different stored
    value
  • 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

6
Passwords as keys how to compute hashed
passwords
  • 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)
    characters
  • encryption performed 25 times
  • brute force attack on alphanumeric password is
    (262610)8 248 , lends itself to dictionary
    attacks

7
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.,
    ROM)

8
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

9
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

10
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

11
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

12
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

13
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

14
Threats in address-based authentication
  • Address Spoofing Sending on behalf of other
    addresses is possible at data link or network
    layer
  • 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

15
Threats in address-based authentication
  • Receiving the messages of others addresses also
    possible
  • 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
    route
  • return traffic too will follow source route and
    can be received in this way

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

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

18
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
Bob
Trudy
5.
5.
4. SYN, ACK t1, SEQ b2
5.
Alice
5.
19
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

20
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

21
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

22
Replay attacks
  • where a valid signed message is copied and later
    resent
  • 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)

23
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,
    hashn(pwd)
  • 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

24
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
    k
  • 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

25
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
    impersonated
  • 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.
    DES)
  • allows off-line guessing of S
  • if str has non random part, j can
    authenticate k

26
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

27
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

28
One-way authentication using public-keys
  • use a digital signature with a digital
    certificate
  • 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,
    SM

29
Mutual authentication using symmetric encryption
  • As discussed in Lecture 3, use a two-level
    hierarchy of keys
  • Usually with a trusted Key Distribution Center
    (KDC)
  • 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

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

31
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

32
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
    parties
  • using a central Authentication Server (AS)
  • various protocols exist using timestamps or
    nonces

33
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

34
Kerberos
  • trusted key server system from MIT
  • provides centralised private-key trusted
    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
  • 4 only for TCP/IP networks, greater installed
    base
  • 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

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

36
Kerberos 4 overview
  • for TCP/IP networks
  • has an Authentication Server (AS)
  • users initially negotiate with AS to identify
    self
  • 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

37
Kerberos 4 overview
38
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

39
Kerberos 4 replicas
  • login session defined as period from login to
    logout
  • 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

40
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

41
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
    B
  • 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
    keys
  • prevents rogue AS from impersonating not just
    its own principals but every principal by
    claiming to be the penultimate KDC in a chain

42
Kerberos for privacy and integrity
  • encrypt and protect (with modified version of DES
    CBC)
  • 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
    transmit
  • message checksum
  • may not have weak collision freedom, may be
    reversible and so leak session key

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

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

45
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

46
Kerberos 5 environmental improvements
  • message layout no longer fixed, uses ASN data
    representation
  • allows use of non IP networks
  • allows use of different encryption schemes
  • may delegate rights to access object, for limited
    time
  • 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
    addresses)
  • 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

47
Kerberos 5 realm hierarchy and chaining
  • hierarchy of realms and chaining is allowed in v5
  • in v4, each realm must be registered in source
    realm
  • now we allow Alice in realm A to impersonate any
    principal
  • to limit impersonation, list transited domains in
    ticket
  • 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
    childrem
  • 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

48
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