Chapter 14 – Authentication Applications
description
Transcript of Chapter 14 – Authentication Applications
![Page 1: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/1.jpg)
Chapter 14 – Authentication Applications
Fourth Editionby William Stallings
Lecture slides by Lawrie Brown
(modified by Prof. M. Singhal, U of Kentucky)
![Page 2: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/2.jpg)
Authentication Applications
• developed to support application-level authentication & digital signatures
• will discuss Kerberos – a private-key authentication service
• discuss X.509 - a public-key directory authentication service
![Page 3: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/3.jpg)
Kerberos
• Authentication service developed as a part of MIT’s Athena project
• provides centralized 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
![Page 4: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/4.jpg)
Athena
• An open distributed environment• Any user can access services from any
workstation• Several security threats exists in such an
environment:– A user impersonate another user– A user may change the network address of a w/s and
may make it look as another w/s– A user may eavesdrop on a session and mount a
replay attak later
![Page 5: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/5.jpg)
Kerberos Requirements
• its first report identified requirements as:– secure– reliable– transparent– scalable
• implemented using an authentication protocol based on Needham-Schroeder
![Page 6: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/6.jpg)
Kerberos v4 Overview
• 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
![Page 7: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/7.jpg)
Kerberos v4 Dialogue
1. obtain ticket granting ticket from AS• once per session
2. obtain service granting ticket from TGT• for each distinct service required
3. client/server exchange to obtain service• on every service request
![Page 8: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/8.jpg)
Kerberos 4 Overview
![Page 9: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/9.jpg)
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, Kerberos servers must share keys and trust each other
![Page 10: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/10.jpg)
Kerberos Realms
![Page 11: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/11.jpg)
Kerberos Version 5
• developed in mid 1990’s to address the deficiencies of v4
• provides improvements over v4• encryption algorithm: DES is weak and vulnerable
to attacks. V5 allows a suit of encryption algorithms.
• V5 breaks away from IP only networks• V4 uses 8bit ticket lifetime.V5 uses start time and
end time.• •
![Page 12: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/12.jpg)
X.509 Authentication Service
• part of CCITT X.500 directory service standards– distributed servers maintaining user info database
• defines framework for authentication services – directory may store public-key certificates– with public key of user signed by certification authority
• also defines authentication protocols • uses public-key crypto & digital signatures
– algorithms not standardised, but RSA recommended
• X.509 certificates are widely used
![Page 13: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/13.jpg)
X.509 Certificates
• issued by a Certification Authority (CA), containing: – version (1, 2, or 3) – serial number (unique within CA) identifying certificate – signature algorithm identifier – issuer X.500 name (CA) – period of validity (from - to dates) – subject X.500 name (name of owner) – subject public-key info (algorithm, parameters, key) – issuer unique identifier (v2+) – subject unique identifier (v2+) – extension fields (v3) – signature (of hash of all fields in certificate)
• notation CA<<A>> denotes certificate for A signed by CA
![Page 14: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/14.jpg)
X.509 Certificates
![Page 15: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/15.jpg)
Obtaining a Certificate
• any user with access to CA can get any certificate from it
• only the CA can modify a certificate • because cannot be forged, certificates can
be placed in a public directory • If there are a large number of users, one
CA may not be able to handle the load• Also it is difficult to propagate the public
key of the CA securely.
![Page 16: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/16.jpg)
Certificate Chaining
• if both users share a common CA then they are assumed to know its public key
• What if both users have their certificates issued by two different CAs? (and one does not know the public key of the other CA)
• Suppose A’s certificate is issued by X1 and B’s by X2
• And A does not know the public key of X2.
(A can not verify the public key of B).
![Page 17: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/17.jpg)
Certificate chaining
• Suppose X1 and X2 have securely exchanged their public keys.
• X1 can prepare a certificate for X2 and sends it to A.
• A can request this certificate from X1, obtain the public key of X2, and then verify B’s certificate.
• Notationally,
X1<<X2>>X2<<B>>
--Chain of two certficates.
--need not be limited to two certificates.
![Page 18: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/18.jpg)
CA Hierarchy
• CAs can certify each other.• CAs are linked by this relation.• CAs can be organized in several structures• X.509 suggests CA's must form a hierarchy • use certificates linking members of hierarchy to
validate other CA's – each CA has certificates for clients (forward) and
parent (backward) • each client trusts parents certificates • enable verification of any certificate from one CA
by users of all other CAs in hierarchy
![Page 19: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/19.jpg)
A CA Hierarchy
![Page 20: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/20.jpg)
CA Hierarchy
• A can verify B’s certificate using the following certificate chain:
X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
-- There is chain of trust also.• Likewise, B can verify A’s public key using the
following certificate chain:
Z<<Y>>Y<<V>>V<<W>>W<<X>>X<<A>>
--can obtain these certificates from the directory.
![Page 21: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/21.jpg)
Certificate Revocation
• certificates have a period of validity• may need to revoke before expiry, e.g.:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
• CA’s maintain list of revoked certificates– the Certificate Revocation List (CRL)– CRL is advertised widely through directory.
• users should check certificates with CA’s CRL
![Page 22: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/22.jpg)
Authentication Procedures
• X.509 includes three alternative authentication procedures:
• One-Way Authentication
• Two-Way Authentication
• Three-Way Authentication
• all use public-key signatures
• It is assumed that the two parties know each other’s public key.
![Page 23: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/23.jpg)
One-Way Authentication
• 1 message ( A->B) used to establish – the identity of A and that message is from A – message was intended for B – integrity & originality of message
• message must include timestamp, nonce, B's identity and is signed by A
• may include additional info for B– E.g., session key
![Page 24: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/24.jpg)
Two-Way Authentication
• 2 messages (A->B, B->A) which also establishes in addition:– the identity of B and that reply is from B – that reply is intended for A – integrity & originality of reply
• reply includes original nonce from A, also timestamp and nonce from B
• may include additional info for A
![Page 25: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/25.jpg)
Three-Way Authentication
• 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized clocks
• has reply from A back to B containing signed copy of nonce from B
• means that timestamps need not be checked or relied upon
![Page 26: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/26.jpg)
X.509 Version 3
• has been recognised that additional information is needed in a certificate – email/URL, policy details, usage constraints
• rather than explicitly naming new fields defined a general extension method
• extensions consist of:– extension identifier– criticality indicator– extension value
![Page 27: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/27.jpg)
Certificate Extensions
Extensions fall into three categories:• key and policy information
– convey additional info about subject & issuer keys, plus indicators of certificate policy
• certificate subject and issuer attributes– support alternative names, in alternative formats for
certificate subject and/or issuer
• certificate path constraints– allow constraints on use of certificates by other CA’s(may restrict the type of certificate issued)
![Page 28: Chapter 14 – Authentication Applications](https://reader033.fdocuments.net/reader033/viewer/2022061505/5681481a550346895db54618/html5/thumbnails/28.jpg)
Summary
• have considered:– Kerberos trusted key server system– X.509 authentication and certificates