Authentication applications

1
Authentication applications

• Digital signatures
• Key management
• Kerberos
• X-509

2
Digital Signatures

• Cryptographic technique analogous to hand-written
  signatures.
• sender (Bob) digitally signs document,
  establishing he is document owner/creator.
• The signiture is verifiable, nonforgeable
  recipient (Alice) can prove to someone that Bob,
  and no one else (including Alice), must have
  signed document

3
Digital Signatures

• Simple digital signature for message m
• Bob signs m by encrypting with his private key
  KB, creating signed message, KB(m)

-
-
Bobs private key
Bobs message, m
(m)
Dear Alice Oh, how I have missed you. I think of
you all the time! (blah blah blah) Bob
Bobs message, m, signed (encrypted) with his
private key
Public key encryption algorithm
4
Digital Signatures (more)
-

• Suppose Alice receives msg m, digital signature
  KB(m)
• Alice verifies m signed by Bob by applying Bobs
  public key KB to KB(m) then checks KB(KB(m) )
  m.
• If KB(KB(m) ) m, whoever signed m must have
  used Bobs private key.

-
-


-

• Alice thus verifies that
• Bob signed m.
• No one else signed m.
• Bob signed m and not m.
• Non-repudiation
• Alice can take m, and signature KB(m) to court
  and prove that Bob signed m.

-
5
Trusted Intermediaries

• Symmetric key problem
• How do two entities establish shared secret key
  over network?
• Solution
• trusted key distribution center (KDC) acting as
  intermediary between entities

• Public key problem
• When Alice obtains Bobs public key (from web
  site, e-mail, diskette), how does she know it is
  Bobs public key, not Trudys?
• Solution
• trusted certification authority (CA)

6
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 Es public key digitally
  signed by CA CA says this is Es public key

Bobs public key
CA private key
certificate for Bobs public key, signed by CA
-
Bobs identifying information
7
Certification Authorities

• When Alice wants Bobs public key
• gets Bobs certificate (from Bob or elsewhere).
• apply CAs public key to Bobs certificate, get
  Bobs public key

Bobs public key
CA public key

8
A certificate contains

• Serial number (unique to issuer)
• info about certificate owner, including algorithm
  and key value itself (not shown)

• info about certificate issuer
• valid dates
• digital signature by issuer

9
Key ManagementPublic-Key Certificate Use
10
Security Concerns

• key concerns are confidentiality and timeliness
• to provide confidentiality must encrypt
  identification and session key info
• which requires the use of previously shared
  private or public keys
• need timeliness to prevent replay attacks
• provided by using sequence numbers or timestamps
  or challenge/response

11
Approaches to distributed security

• Rely on each client WS (workstation) to assure
  identity of its user and rely on each server to
  enforce a security policy based on user ID.
• Require that client systems authenticate to
  servers, but trust the clients concerning
  identity of its user.
• Require the user to prove identity for each
  service invoked and each server to prove its
  identity to clients.

12
KERBEROS

• In Greek mythology, a many headed dog, the
  guardian of the entrance of Hades

13
KERBEROS

• Users wish to access services on servers.
• Three threats exist
• User pretend to be another user.
• User alter the network address of a workstation.
• User eavesdrop on exchanges and use a replay
  attack.

14
Requirements for Kerberos design

• Secure
• Reliable
• Transparent
• Scalable

15
KERBEROS

• Provides a centralized authentication server to
  authenticate users to servers and servers to
  users.
• Relies on conventional encryption, making no use
  of public-key encryption
• Two versions version 4 and 5
• Version 4 makes use of DES

16
Kerberos Version 4

• Terms
• C Client
• AS authentication server
• V server
• IDc identifier of user on C
• IDv identifier of V
• Pc password of user on C
• ADc network address of C
• Kv secret encryption key shared by AS an V
• TS timestamp
• concatenation

17
A Simple Authentication Dialogue

• C -gt AS IDc Pc IDv
• AS -gt C Ticket
• C -gt V IDc Ticket
• Ticket EKvIDc ADc IDv
• Problem transmission of password in the open let
  an intruder to capture it

18
A Better Authentication Dialogue

• Once per logon session
• (1) C -gt AS IDc IDtgs
• (2)AS -gt C EkcTickettgs
• Once per type of service
• (3)C-gtTGS Idc IdvTickettgs
• (4) TGS -gt C Ticketv
• Once per service session
• (5) C-gt V IDc Ticketv
• Tickettgs EKtgsIDc ADc
  IdtgsTS1Lifetime1
• Ticketv EKvIDc ADc IdvTS2Lifetime2

19
Version 4 Authentication Dialogue

• Problems
• Lifetime associated with the ticket-granting
  ticket
• If too short ? repeatedly asked for password
• If too long ? greater opportunity to replay
• The threat is that an opponent will steal the
  ticket and use it before it expires
• The servers may have to authenticate themselves
  to the users

20
Version 4 Authentication Dialogue

• Authentication Service Exhange To obtain
  Ticket-Granting Ticket
• C -gt AS IDc IDtgs TS1
• AS -gt C EKc Kc,tgs IDtgs TS2
  Lifetime2 Tickettgs

Ticket-Granting Service Echange To obtain
Service-Granting Ticket (3) C -gt TGS
IDv Tickettgs Authenticatorc (4) TGS -gt
C EKc Kc,v IDv TS4 Ticketv
Client/Server Authentication Exhange To Obtain
Service (5) C -gt V Ticketv
Authenticatorc (6) V -gt C EKc,vTS5
1
21
Overview of Kerberos
22
Kerberos realms

• Realm - a Kerberos server, a number of clients
  and a number of application servers
• Kerberos server must have user ID and hashed
  password of all participating users in its
  database
• Kerberos server must share a secret key with each
  server. All servers are registered with the
  Kerberos server.
• Kerberos servers in each interoperating realm
  shares a secret key with the server in the other
  realm. The two Kerberos servers are registered
  with each other.

23
Request for Service in Another Realm
24
Environmental shortcomings of Version 4

• Encryption system dependence (DES)
• Internet protocol dependence
• Message byte ordering
• Ticket lifetime
• Authentication forwarding
• Interrealm authentication

25
Technical deficiences of Version 4

• Double encryption (removed in V5)
• PCBC encryption (standard CBC in V5)
• Session keys (subsession keys in V5)
• Password attacks (preauthentication in V5 to make
  attack more difficult)

26
Kerberos Encryption Techniques
27
PCBC Mode
28
Kerberos - in practice

• Currently have two Kerberos versions
• 4 restricted to a single realm
• 5 allows inter-realm authentication, in beta
  test
• Kerberos v5 is an Internet standard
• specified in RFC1510, and used by many utilities
• To use Kerberos
• need to have a KDC on your network
• need to have Kerberised applications running on
  all participating systems
• major problem - US export restrictions
• Kerberos cannot be directly distributed outside
  the US in source format ( binary versions must
  obscure crypto routine entry points and have no
  encryption)
• else crypto libraries must be reimplemented
  locally

29
Why Study Kerberos v4
(Why doesn't everyone switch to v5)
Kerberos V4 is working well in many systems
Switching to V5 requires stopping the network
and upgrading every host at once before restart
Kerberos V5 is inefficient in some ways compared
to V4

Specified in ASN.1 (abstraction good and bad)

Example 11 bytes required for 4-byte IP address.
29
30
X.509 Authentication Service

• Distributed set of servers that maintains a
  database about users.
• Based on public key cryptography and digital
  signiture
• Each certificate contains the public key of a
  user and is signed with the private key of a CA.
• Is used in S/MIME, IP Security, SSL/TLS and SET.
• RSA is recommended to use.
• Unspecified hash algorithm.

31
X.509 Formats
32
Typical Digital Signature Approach
33
Certificate notation

• CAltltAgtgt CAV,SN, AI, CA, Ta, A, Ap
• YltltXgtgt certificate of user X issued by
  certificate authority Y
• YI the signing of I by Y. It consists of I
  with an encrypted hash code appended

34
Obtaining a Users Certificate

• Characteristics of certificates generated by CA
• Any user with access to the public key of the CA
  can recover the user public key that was
  certified.
• No part other than the CA can modify the
  certificate without this being detected.

35
Different CAs

• Let A has certificate from X1, while B has
  certificate from X2.
• A obtain from directory the certificate of X2,
  signed by X1.A can obtain X2s public key from
  its certificate and verify it by means of X1s
  signature on the certificate.
• A then goes back to the directory and obtains the
  certificate of B signed by X2. A can verify the
  signature and securely obtain Bs public key

36
Notation

• A is certified by X1, B is certified by X2
• A obtains Bs public key
  X1ltltX2gtgt X2ltltBgtgt
• B obtains As public key
  X2ltltX1gtgtX1ltltAgtgt

37
X.509 CA Hierarchy
38
Chain of certificates

• From A to B
• XltltWgtgt WltltVgtgt VltltYgtgt YltltZgtgt ZltltBgtgt
• From B to A
• ZltltYgtgt YltltVgtgt VltltWgtgt WltltXgtgt XltltAgtgt

39
Revocation of Certificates

• Reasons for revocation
• The users secret key is assumed to be
  compromised.
• The user is no longer certified by this CA.
• The CAs certificate is assumed to be
  compromised.
• Each CA must maintain Certificate Revocation List
  (CRL)

40
Authentication Procedures

• Make use of public-key signatures
• One way
• establishes the identity of A and that the
  message was generated by A
• That the message is intended for B
• The integrity and originality of the message

41
Authentication Procedures

• Two-way in addition
• establishes the identity of B and that the
  message was generated by B
• That the message is intended for A
• The integrity and originality of the message
• Three-way in addition
• a final message from A to B is included, which
  contains a signed copy of the nonce rb. The
  intent is that timestamps need not to be checked

42
Authentication Procedures
43
Requirements not satisfied by X509 Version 2

• Subject field inadequate
• - to convey identity of a key owner
  - for
  applications using Internet email address etc,
• Need to indicate security policy information
• Need to limit damage from a faulty or malicious
  CA
• Ability to identify different keys used by the
  same owner

44
X.509 Version 3

• Approach - optional extensions which may be added
  to Version 2
• Extensions categories
  -
  key and policy information,
  - subject
  and issuer attributes,
  - certification
  path constraints

45
Key and policy information

• Authority key identifier
• Subject key identifier
• Key usage
• Private key usage period
• Certificate policies
• Policy mapping

46
Certificate Subject and Issuer Attributes

• Subject alternative name
• Issuer alternative name
• Subject directory attributes

47
Certification Path Constraints

• Basic constraints
• Name constraints
• Policy constraints

48
Public Key Infrastructure Model

• End entity
• Certification authority
• Registration authority
• CRL issuer
• Repository

49
PKIX Management functions

• Registration
• Initialization
• Certification
• Key pair recovery
• Key pair update
• Revocation request
• Cross certification