Authentication

Published on June 2016 | Categories: Documents | Downloads: 88 | Comments: 0 | Views: 221
of 47
Download PDF   Embed   Report

Comments

Content

Chapter 5
Authentication Applications
//Revised by Prof. M. Singhal// Henric Johnson Blekinge Institute of Technology,Sweden http://www.its.bth.se/staff/hjo/ [email protected] Henric Johnson
1

Outline
‡ ‡ ‡ ‡ Security Concerns Kerberos X.509 Authentication Service Recommended reading and Web Sites

Henric Johnson

2

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
Henric Johnson 3

KERBEROS

In Greek mythology, a many headed dog, the guardian of the entrance of Hades
Henric Johnson 4

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.
Henric Johnson 5

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
Henric Johnson 6

Kerberos Version 4
‡ Notations:
² ² ² ² ² ² ² ² ² ² 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 || = concatenationHenric Johnson

7

A Simple Authentication Dialogue
(1) C ¼ AS:
(2) AS ¼ C: (3) C ¼ V:

IDc || Pc || IDv
Ticket

IDc || Ticket

Ticket = EKv[IDc || Pc || IDv]

Henric Johnson

8

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

Henric Johnson

9

Version 4 Authentication Dialogue
Authentication Service Exhange: To obtain Ticket-Granting Ticket (1)
(2)

C ¼ AS:
AS ¼ C:

IDc || IDtgs ||TS1
EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs]

Ticket-Granting Service Echange: To obtain Service-Granting Ticket
(3) C ¼ TGS: (4) TGS ¼ C: IDv ||Tickettgs ||Authenticatorc EKc [Kc,¨v|| IDv || TS4 || Ticketv]

Client/Server Authentication Exhange: To Obtain Service
(5) C ¼ V: (6) V ¼ C: Ticketv || Authenticatorc EKc,v[TS5 +1]
Henric Johnson 10

Overview of Kerberos

Henric Johnson

11

Kerberos Realms and Multiple Kerberi
‡ A Kerberos realm consists of: >A Kerberos server, a number of clients, and a number of applications servers. -All users are registered with the Kerberos server (hashed passwords are in Kerberos database). -Kerberos server shares a secret with each server.
Henric Johnson 12

Kerberos Realms and Multiple Kerberi
‡ Due to size and other considerations, a system may consist of several Kerberos realms. >A user in one realm may need to access servers in other realms. >Servers in a realm may provide services to users in other realms (provided they are authenticated).
Henric Johnson 13

Kerberos Realms and Multiple Kerberi
‡ Kerberos provides a mechanism for inter-realm authentication. ‡ A third requirement is added: ´The Kerberos server in each realm shares a secret key with the server in other realms.µ

Henric Johnson

14

Kerberos Realms and Multiple Kerberi
‡ Kerberos server in one realm must trust the Kerberos server in other realm to authenticate its users. ‡ Thus, Kerberos server in one realm must trust the Kerberos server in other realm.

Henric Johnson

15

Request for Service in Another Realm

Henric Johnson

16

Difference Between Version 4 and 5
‡ Encryption system dependence - V.4 requires DES -V.5 allows many encryption techniques -Ciphertext is tagged with encryption type id. ‡ Internet protocol dependence -V.4 requires use of IP -V.5 allows other network protocols
Henric Johnson 17

Difference Between Version 4 and 5
‡ Ticket lifetime -V.4 encodes it in 8 bit quantity -V.5 allows explicit start and end times. ‡ Authentication forwarding -V.4 does not allow credentials issued to one client to be forwarded to other host for use by some other clients. -V.5 allows it. ‡ Interrealm authentication -Easier in V.5
Henric Johnson 18

Kerberos Encryption Techniques
‡ Password to Key Transformation: >Kerberos passwords consist of characters of any length. >Converted into encryption key that is stored in Kerberos database. >Procedure is explained next:

Henric Johnson

19

Kerberos Encryption Techniques
‡ Password to Key Transformation:« 1. Character string s is packed into a bit string, b. 2. Bit string is compacted into 56 bits by aligning the bits into ´fanfoldµ fashion. 3. The output is treated as 56 bit DES key.
Henric Johnson 20

Kerberos Encryption Techniques
‡ Password to Key Transformation:« 4. To make a 64 bit DES key, the 56 bits are expanded into 64 bits. 5. The original password is encrypted using CBC mode of DES with the key. 6. The output 64 bits denote the key associated with the password.
Henric Johnson 21

Kerberos Encryption Techniques

Henric Johnson

22

Propagating CBC Mode (PCBC)
‡ V4 Kerberos uses an extension of CBC, called PCBC. ‡ Input to encryption are XOR of: >Current plaintext block, >Preceding ciphertext block, and >Preceding plaintext block.
Henric Johnson 23

PCBC Mode

Henric Johnson

24

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 ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡
Henric Johnson 25

X.509 Authentication Service
‡ Distributed set of servers that maintains a database about users. ‡ 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. ‡ Based on public-key cryptography and digital signatures. ‡ RSA is recommended to use.
Henric Johnson 26

X.509 Authentication Service«
‡ Public-Key Certificates: >Heart of the X.509 scheme. >User certificates are created by some trusted certificate authority (CA). >Directory server is not responsible for creation of certificates. >It merely provides an access to them.
Henric Johnson 27

X.509 Formats

Henric Johnson

28

Certificates
‡ Version: indicates the version number. ‡ Serial number: An integer value unique within the issuing CA. ‡ Signature Algo. Identifier: algo. Used to sign the certificate. ‡ Issuer name: the name of the CA that created and signed the certificate.
Henric Johnson 29

Certificates
‡ Period of Validity: period during which the certificate is valid. ‡ Subject name: subject/user whose public key is certified. ‡ Subject·s Public Key Info.: The public key of the user and id of the algo. to be used. ‡ Issuer unique Id.: Identifies the issuing CA.
Henric Johnson 30

Certificates
‡ Subject Unique Id.: identifies the subject. ‡ Extensions: A set of one or more extension fields.. ‡ Signature: Hash code of all other fields encrypted with the CA·s private key.
Henric Johnson 31

Typical Digital Signature Approach

Henric Johnson

32

Obtaining a User·s 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 party other than the CA can modify the certificate without this being detected. ² No need to protect certificates.
Henric Johnson 33

Multiple CAs
‡ If community of users is large, many CAs may be required to serve it. ‡ Each provides public keys to a segment of users. ‡ Each participating user must have CA·s correct public key.

Henric Johnson

34

Multiple CAs«
‡ Suppose user A has obtained a certificate from CA X1. ‡ User B has obtained a certificate from CA X2. ‡ If user A does not know the public key of X2, B·s certificate is useless To A. ‡ How to make the certificates issued by other CAs useful to as many users.
Henric Johnson 35

Multiple CAs«
A Solution: ´A CA also certifies the public keys of other CAs.µ > CAs securely exchange their public keys. ‡ User A can obtain the certificate of X2 signed by X1. //A knows X1·s public key and can obtain X2·s public key from the certificate.// ‡ A now obtains B·s certificate (issued by X2) and can obtain B·s public key.
Henric Johnson 36

Multiple CAs«
‡ User A has used a chain of certificates to obtain B·s public key. Notationally: this chain is expressed as: X1<<X2>> X2<<B>> ‡ The chain need not be limited to two. ‡ A chain may consist of any number of CAs.
Henric Johnson 37

Multiple CAs«
Example: X1<<X2>>X2<<X3>>«««..XN<<B>> ‡ Each pair of CAs in the chain (Xi,Xi+1) have created a certificate for each other. ‡ All these certificates of CAs by CAa need to be in directory. ‡ Users need to know how they are linked to follow the paths.
Henric Johnson 38

Multiple CAs«
‡ X.509 suggest that the CAs be arranged in a hierarchy. ‡ Navigation is easier. ‡ Example: (See picture in next slide) A acquires the following certificates to obtain the certificate for B: X<<W>>W<<V>>V<<Y>>Y<<Z>>Z<<B>>
Henric Johnson 39

X.509 CA Hierarchy

Henric Johnson

40

Revocation of Certificates
‡ A CA can revoke a certificate prematurely. ‡ Revoked certificates can not be used. ‡ Revoked certificates are placed on a Certification Revocation List (CRL). ‡ A certificate user must verify the certificate.
Henric Johnson 41

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 CA·s certificate is assumed to be compromised.

Henric Johnson

42

Authentication
‡ CA must authenticate/verify an applicant before issuing it a certificate for it. //involves checking if an applicant has the matching private keys.// 1. CA A : Epub-keyA(FivePM => Class over) 2. A decrypts it with its private key and 3. A CA: (Class over => FivePM). >>> X.509 specifies three authentication procedures.
Henric Johnson 43

Authentication«
‡ Procedures make use of public-key cryptography. ‡ Assumed that two parties know the public key of each other. 1. One-way authentication: ´Identity of one party is verified.µ

Henric Johnson

44

Authentication«
2. Two-way authentication: ´Identity of both parties is verified.µ 3. Three-way authentication: >Final message from A to B contains a signed copy of the nonce r_B. > Timestamp is not needed to thwart a replay attack.
Henric Johnson 45

Authentication Procedures

Henric Johnson

46

Recommended Reading and WEB Sites
‡ www.whatis.com (search for kerberos) ‡ Bryant, W. Designing an Authentication System: A Dialogue in Four Scenes.
http://web.mit.edu/kerberos/www/dialogue.html

‡ Kohl, J.; Neuman, B. ´The Evolotion of the Kerberos Authentication Serviceµ
http://web.mit.edu/kerberos/www/papers.html

‡ http://www.isi.edu/gost/info/kerberos/
Henric Johnson 47

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close