Network Security

Essentials
Chapter 4
Fourth Edition
by William Stallings

Lecture slides by Lawrie Brown

 Chapter 4 – Key Management
and Distribution
No Singhalese, whether man or woman,
would venture out of the house without a
bunch of keys in his hand, for without such
a talisman he would fear that some devil
might take advantage of his weak state to
slip into his body.
—The Golden Bough, Sir James George
Frazer
 Key Management and
Distribution
 topics of cryptographic key management /
key distribution are complex
 cryptographic, protocol, & management issues
 symmetric schemes require both parties to
share a common secret key
 public key schemes require parties to
acquire valid public keys
 have concerns with doing both
 Key Distribution
 symmetric schemes require both parties to
share a common secret key
 issue is how to securely distribute this key
 whilst protecting it from others
 frequent key changes can be desirable
 often secure system failure due to a break
in the key distribution scheme
 Key Distribution
 given parties A and B have various key
distribution alternatives:
1. A can select key and physically deliver to B
2. third party can select & deliver key to A & B
3. if A & B have communicated previously can
use previous key to encrypt a new key
4. if A & B have secure communications with a
third party C, C can relay key between A & B
 Kerberos
 trusted key server system from MIT
 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
 Kerberos Requirements
 its first report identified requirements as:
 secure
 reliable
 transparent
 scalable
 implemented using an authentication
protocol based on Needham-Schroeder
 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
 using a complex protocol using DES
Kerberos v4 Dialogue
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
Kerberos Realms
 Kerberos Version 5
 developed in mid 1990’s
 specified as Internet standard RFC 1510
 provides improvements over v4
 addresses environmental shortcomings
• encryption alg, network protocol, byte order, ticket
lifetime, authentication forwarding, interrealm auth
 and technical deficiencies
• double encryption, non-std mode of use, session
keys, password attacks
Kerberos v5 Dialogue
 X.509
Certificate
Use
 X.509 Certificates
 issued by a Certification Authority (CA), containing:
 version V (1, 2, or 3)
 serial number SN (unique within CA) identifying certificate
 signature algorithm identifier AI
 issuer X.500 name CA)
 period of validity TA (from - to dates)
 subject X.500 name A (name of owner)
 subject public-key info Ap (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
X.509 Certificates
 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
 CA Hierarchy
 if both users share a common CA then they are
assumed to know its public key
 otherwise 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
CA Hierarchy Use
 Certificate Revocation
 certificates have a period of validity
 may need to revoke before expiry, eg:
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)
 users should check certificates with CA’s CRL
 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
 Certificate Extensions
 key and policy information
 convey 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
Public Key Infrastructure
 PKIX Management
 functions:
 registration
 initialization
 certification
 key pair recovery
 key pair update
 revocation request
 cross certification
 protocols: CMP, CMC
 Federated Identity
Management
 use of common identity management scheme
 across multiple enterprises & numerous applications
 supporting many thousands, even millions of users
 principal elements are:
 authentication, authorization, accounting,
provisioning, workflow automation, delegated
administration, password synchronization, self-service
password reset, federation
 Kerberos contains many of these elements
Identity Management
 Identity
Federation
 Standards Used
 Security Assertion Markup Language (SAML)
 XML-based language for exchange of security
information between online business partners
 part of OASIS (Organization for the
Advancement of Structured Information
Standards) standards for federated identity
management
 e.g. WS-Federation for browser-based federation
 need a few mature industry standards
Federated Identity Examples