Authentication Applications

1
Authentication Applications

• Kerberos
• X.509

2
Why Kerberos?
Kerberos

• Environment
• Open distributed Environment
• Server needs
• To restrict access to authorized user
• To authenticate requests for services
• Following threats
• A user may gain access and pretend to be another
  user
• Alter network address of workstation and use as
  impersonated workstation
• Eavesdrop on exchanges and use a replayattack

3
Motivation
Kerberos

• Kerberos protocol assumes distributed
  client/server architecture
• In each architecture,one or more Kerberos servers
  employed
• Requirements for Kerberos
• Secure
• Eavesdropper cannot have information to
  impersonate a user
• Strong enough not to find potential weak link
• Reliable
• All services rely on Kerberos for access control
• availability of Kerberos ? availability of
  supported service
• For reliable, employ distributed server
  architecture for ones backing up another
• Transparent
• Scalable

4
A Simple Authentication Dialogue
Kerberos Version 4.

• Assume authenticate server knows
• ids and passwords of all users
• Service permission of all users
• Problems
• Password is revealed on the network
• Entering password needed at each service

5
A More Secure Authentication Dialogue
Kerberos Version 4.
Once per user logon Sessions
Once per type of services
Once per Service Session

• Problems
• Tickets are revealed in network
• If spoofing is possible then replay attack
• User must authenticate servers to service

6
The Version 4 Authentication Dialogue(1/3)
Kerberos Version 4.

• Kerberos version 4 provides
• Using session key between clients and ticket
  granting server to prevent replay attack
• Mutual authentication between user and server by
  challenge-response

7
The Version 4 Authentication Dialogue(2/3)
Kerberos Version 4.
8
The Version 4 Authentication Dialogue(3/3)
Kerberos Version 4.
Overview of Kerberos
9
Kerberos Realms and Multiple Kerberi(1/2)
Kerberos Version 4.

• Realm
• The environment that one Kerberos server can
  manage the authentication process
• The environment of one realm
• The Kerberos server of one realm has all users ID
  and hashed password of all users in the realm
• The Kerberos server must share a secret key with
  each server
• All servers are registered with the Kerberos
  server
• Users in one realm may need access to servers in
  other realms
• Kerberos provides a mechanism for supporting
  inter-realm authentication.
• Only if Kerberos servers in inter-realms shares a
  secret key
• Assume the Kerberos servers trust each other.

10
Kerberos Realms and Multiple Kerberi(2/2)
Kerberos Version 4.
11
Difference Between Version 4 and 5(1/2)
Kerberos Version 5.

• Environmental shortcomings
• Encryption system dependence
• Any encryption algorithms can be used in v5 but
  only DES is possible in v4
• Internet protocol dependence
• Only IP is possible ? to use any internet
  protocol
• Message byte ordering
• Own choosing ? use Abstract Syntax Notation one
  (ASN.1) and Basic Encoding Rules (BER)
• Ticket Life Time
• 1280 minitues(8bit) ? any length of time(any
  length of bits)
• Authentication Forwarding
• (eg. client ? print server and print server ?
  file server to use the file of client)
• Inter-realm authentication
• Less complexity than v4

12
Difference Between Version 4 and 5(2/2)
Kerberos Version 5.

• Technical deficiencies
• Double encryption
• PCBC encryption
• In v5, Standard CBC is used
• Session keys
• In v5, subsession key for only one connection can
  be used
• Password attacks

13
The Version 5 Authentication Dialogue(1/3)
Kerberos Version 5.

• Authentication Service Exchange
• New elements
• Realm indicates realm of user
• Options Used to request that certain flags be
  set in the returned ticket
• Times Used by the client to request the
  following time setting in the ticket
• Nonce A random value to refresh the message
  (preventing replay attack)
• Adds Nonce to refresh message and Flags field to
  have new functionality

14
The Version 5 Authentication Dialogue(2/3)
Kerberos Version 5.

• Ticket-Granting Service Exchange
• V5 Adds request time and options for ticket and
  nonces in comparison to v4
• Other contents are similar to v4

15
The Version 5 Authentication Dialogue(3/3)
Kerberos Version 5.

• Client/Server Authentication Exchange
• New fields
• Subkey clients choice for an encryption key to
  protect specified session if omitted ticket
  session key( ) is used
• Sequence number
• Counting messages sent to detect replays

16
The flags
Kerberos Version 5.
17
X.509 Authentication Service
X.509

• X.509
• Define authentication protocols based on the use
  of public key certificates
• Part of X.500, define a directory service
• The directory is used as a repository of
  certificates
• In certificate(as you see in chapter 6)
• User identity
• Public-key of the user
• Signature by using the private key of trusted
  certificate authority
• Used in Various contexts
• S/MIME, IP Security , SSL/TLS and SET
• Based on public-key cryptography and digital
  signatures
• Not dictate specified algorithm but recommend RSA
• Directory
• A server of distributed set of servers that
  maintain user information

18
Certificates(1/4)
X.509 Authentication Service

• The heart of the X.509 scheme
• Associated with each user
• Created by some trusted certification
  authority(CA) and placed in the directory by CA
• The directory is merely storing certificate

19
Certificate(2/4)
X.509 Authentication Service

• Format of certificates
• Version (v1,v2,v3)
• Serial number
• Signature algorithm Identifier
• Issuer name
• Period of validity
• Subjects public-key information
• Issuer unique identifier
• Subject unique identifier
• Extension
• Signature

20
Certificate(3/4)
X.509 Authentication Service

• Example of Certificate

21
Certificate(4/4)
X.509 Authentication Service
22
Obtaining a Users Certificate(1/4)
X.509 Authentication Service

• Using notation to define a certificate
• CAltltAgtgtCAV,SN,AI,CA,TA,A,Ap
• YltltXgtgt certificate of user X issued by Y(CA)
• YI signing of I by Y , consists of I
  with encrypted hash code
• Characteristics
• Any user with access to the public key of the CA
  can recover all of the user certificate certified
  by the CA
• No one except CA can modify any users
  certificate without detected
• If all user subscribe the same CA, directly get
  any certificate of users using directory of CA.
• But single CA for large user is impractical
• CA must sign all user certificates
• CAs certificates must be distributed to all
  users
• CA must provided his public-key to be distributed
  securely

23
Obtaining a Users Certificate (2/4)
X.509 Authentication Service

• Hierarchical structure of CA
• Exist some CAs
• Distribute its public-key securely to some
  fraction of users
• The way to get certificate of users issued by
  different CA needed
• Because the user issued by A(CA) cannot know the
  public key of B(CA)
• How to get other users certificate that exist
  many CAs
• Assume user A has the certificate of X1 and B has
  that of X2
• Procedure
• A gets X2s certificate signed by X1 in directory
• A can verify X2s certificate by X1s public key
• Then A can get X2s public key by X2s
  certificate
• B does the same operation for A
• A gets Bs certificate signed by X2 in directory
• A can verify Bs certificate by X2s public key
• In notation,
• A X1ltltX2gtgtX2ltltBgtgt
• B X2ltltX1gtgtX1ltltAgtgt

24
Obtaining a Users Certificate (3/4)
X.509 Authentication Service

• procedure of exchanging certificate between A and
  B
• Using certificate chain
• A XltltWgtgtWltltVgtgtVltltYgtgtYltltZgtgtZltltBgtgt
• B ZltltYgtgtYltltVgtgtVltltWgtgtWltltXgtgtXltltAgtgt

25
Obtaining a Users Certificate (4/4)
X.509 Authentication Service

• Example

26
Revocation of Certificate
X.509 Authentication Service

• Reason of revoking certificate
• Users (private) key assumed to be compromised
• User is no longer certified by the CA
• CAs certificates assumed to be compromised
• CA must maintain the list of revoked certificated
  that not expired
• Serial number is unique in each certificate
• If user receive a certificate, user must check
  whether it is revoked

27
Authentication Procedures
X.509 Authentication Service

• X.509 define the authentication procedure between
  entity A and B
• Assume
• each has the certificate of the other
• All certificates are valid certificate
• Three authentication way
• One-way
• Two-way
• Three-way

28
X.509 v3(1/2)
X.509 Authentication Service

• X.509 version convey all of information that
  recent design and implementation
• Following requirements not satisfied by version 2
• Subject field is not adequate to convey all IDs
  of key owner to public key user
• Subject field is inadequate for many
  applications(e-mail , URL ,..)
• Need to security policy information
• Setting constraint of using particular
  certificate for reducing damages of certificates
  issued by malicious CA
• Using separate keys in the same key owner in
  different times
• For update key pair or exceptional circumstances

29
X.509 v3(2/2)
X.509 Authentication Service

• Additional information in v3
• Key and policy information
• Authority key identifier
• Subject key identifier
• Key usage
• Private-key usage period
• Certificate policies
• Policy mapping
• Certificate Subject and Issuer Attributes
• Subject alternative name
• Issuer alternative name
• Subject directory attributes
• Certification Path Constraints
• Basic constraints
• Name constraints
• Policy constraints

30
Application
X.509 Authentication Service

• Secure E-mail

31
Application
X.509 Authentication Service
???
??
http//insecret.co.kr ?? ???? ??? ?? ? ????.