Скачать презентацию Chapter 4 Authentication Applications 1 Outline Скачать презентацию Chapter 4 Authentication Applications 1 Outline

2142d2f77b06c617383936815b547d7a.ppt

  • Количество слайдов: 42

Chapter 4 Authentication Applications 1 Chapter 4 Authentication Applications 1

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

Security Concerns • key concerns are confidentiality and timeliness • to provide confidentiality must 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 – A CAPTCHA (Completely Automated Public Turing Test to tell Computers and Humans Apart) 3

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

KERBEROS • Users wish to access services on servers. • Three threats exist: – KERBEROS • Users wish to access services on servers. • Three threats exist: – User pretends to be another user. – User alters the network address of a workstation. – User eavesdrops on exchanges and uses a replay attack. 5

KERBEROS • Provides a centralized authentication server to authenticate users to servers and servers 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 6

Kerberos Version 4 • Terms: – – – – – C = Client AS 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 and V TS = timestamp || = concatenation 7

A Simple Authentication Dialogue (1) C AS: IDc || Pc || IDv (2) AS A Simple Authentication Dialogue (1) C AS: IDc || Pc || IDv (2) AS C: Ticket (3) C V: IDc || Ticket = EKv[IDc || ADc || IDv] 8

A Simple Authentication Dialogue Pc=password of client c 1 - ID + v + A Simple Authentication Dialogue Pc=password of client c 1 - ID + v + ID Pc t Ticke 2 - 3 - ID c +T icke t Ticket=Ekv[IDc, ADc, IDv] 9

Version 4 Authentication Dialogue • Problems: – Lifetime associated with the ticket-granting ticket – 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 • Requirement : TGS or AS must able to prove that the person using the ticket is the same person to whom the ticket was issued 10

Version 4 Authentication Dialogue IDC, IDtgs EKC(Tickettgs) 사용자 로그온시 한번 AS 티켓 승인 티켓 Version 4 Authentication Dialogue IDC, IDtgs EKC(Tickettgs) 사용자 로그온시 한번 AS 티켓 승인 티켓 Ticket. TGS=EKtgs[IDC, ADC, IDtgs, Lifetime 1] C 서비스타입마다 한번 IDC, IDV, Tickettgs Ticket. V TGS 서비스 승인 티켓 Ticket. V=EKV[IDC, ADC, IDV, Lifetime 2] IDc, Ticket. V V 서비스 세션당 한번 TGS : Ticket Granting Server 11

Version 4 Authentication Dialogue 1. 클라이언트는 ID와 TGS ID를 인증 서버에 전송 2. 인증 Version 4 Authentication Dialogue 1. 클라이언트는 ID와 TGS ID를 인증 서버에 전송 2. 인증 서버는 티켓(티켓 승인 티켓) 생성후 클라이언트에 전송, 이때 클라이언 트는 사용자의 패스워드 입력을 요구 * 티켓은 재사용 방지를 위해 유효기간(lifetime)을 포함 3. 클라이언트는 사용자 ID, 요구하는 서비스 ID, 티켓 승인 티켓을 TGS에 전송 함으로써 서비스 승인 티켓 요구 4. TGS는 들어온 티켓을 복호하고 ID의 존재여부, 복호의 성공여부, 유효기간 확 인, ID/네트워크 주소 점검 후 접속 승인 티켓 발급 5. 클라이언트는 서비스 접속 요구(ID / 서비스 승인 티켓), 서비스 서버는 이것을 인증한다. 단 한번의 패스워드 입력 및 사용자 패스워드 보호 가능한 시나리오 12

Version 4 Authentication Dialogue - Summary Authentication Service Exhange: To obtain Ticket-Granting Ticket (1) Version 4 Authentication Dialogue - Summary Authentication Service Exhange: To obtain Ticket-Granting Ticket (1) C AS: IDc || IDtgs ||TS 1 (2) AS C: EKc [Kc, tgs|| IDtgs || TS 2 || Lifetime 2 || Tickettgs] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C TGS: (4) TGS C: IDv ||Tickettgs ||IDc EKc [Kc, ¨v|| IDv || TS 4 || Ticketv] Client/Server Authentication Exhange: To Obtain Service (5) C V: (6) V C: Ticketv ||IDc EKc, v[TS 5 +1] 13

Version 4 Authentication Dialogue ticket. TGS=EKtgs[IDc, ADc, Once per user logon session 1 - Version 4 Authentication Dialogue ticket. TGS=EKtgs[IDc, ADc, Once per user logon session 1 - c+ ID tgs ID et. T ck [Ti c K E 2 - IDtgs, TS 1, Life. Time 1 ] S] G Once per type of service IDc+IDv t. TGS+ 3 - Ticke 4 -Ticket. V 14

Version 4 Authentication Dialogue Once per service session 5 - Ticket. V+ IDc Ticket. Version 4 Authentication Dialogue Once per service session 5 - Ticket. V+ IDc Ticket. V=EKv[IDc, ADc, IDv, Ts 2, Lifetime 2] 15

Overview of Kerberos 16 Overview of Kerberos 16

Weakness of Kerberos V 4. * 티켓 승인 티켓과 관련된 유효기간의 문제 유효기간이 매우 Weakness of Kerberos V 4. * 티켓 승인 티켓과 관련된 유효기간의 문제 유효기간이 매우 짧다면, 패스워드의 반복 입력이 요구됨 유효기간이 매우 길다면, 침입자의 재전송 공격 가능성 증가 (패킷을 가로채서 가지고 있다가, 사용자 로그 아웃 후 네트워크 주 소를 위조한 다음 단계 3의 메시지를 TGS에 재전송 공격 가능) 이를 방지하기 위해서는, 서비스 사용자가 티켓이 발급된 사용자 라는 것의 증명이 요구됨 * 서버의 인증 가짜 서버가 사용자가 입력한 정보를 가로채서 이용할 수 있음 (IP Spoofing) 17

Kerboros Realms • a Kerberos environment consists of: – a Kerberos server – a Kerboros 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 18

Request for Service in Another Realm(V. 5) 19 Request for Service in Another Realm(V. 5) 19

Difference Between Version 4 and 5 • • • Encryption system dependence (V. 4 Difference Between Version 4 and 5 • • • Encryption system dependence (V. 4 DES) Internet protocol dependence Message byte ordering Ticket lifetime Authentication forwarding Interrealm authentication 20

Kerberos V. 5 • Version 4의 결점 보완 – 암호화 시스템에 대한 의존 : Kerberos V. 5 • Version 4의 결점 보완 – 암호화 시스템에 대한 의존 : DES 사용(DES의 수출제한) • Version 5는 다른 암호 알고리즘 사용 가능 – 인터넷 프로토콜에 대한 의존 : IP 주소 사용 • Version 5는 다른 형식의 주소 사용 가능 – 메시지 바이트 순서 : 순서 표시 고정 • Version 5 : ASN. 1 (Abstract Syntax Notation)과 BER (basic ending rules)인코딩 규칙 표준 사용 (ITU-T X. 690) – 티켓 유효시간 : 최대 28*5 = 1280 분 동안만 사용 가능 • Version 5 : 시작 시간과 끝시간 표시(충분한 유효시간) – 인증의 발송 (forwarding) 이 불가능 • Version 5에서는 가능 – 상호 인증 • Version 5에서는 Kerberos 대 Kerberos의 상호 인증이 가능 21

Kerberos V. 5 • 이중 암호화 – 타겟 서버의 비밀키 + 클라이언트 비밀키 – Kerberos V. 5 • 이중 암호화 – 타겟 서버의 비밀키 + 클라이언트 비밀키 – 두번째 암호는 필요 없음 : 버전 5에서는 제거 • PCBC (Propagating Cipher Block Chaining) 암호화 – 버전 4에서는 DES의 비표준 모드인 PCBC 모드 사용 : 공격에 취약 – 버전 5에서는 표준 모드인 CBC (Cipher Block Chaining) 모드 사용 • 세션키 : 버전 4에서는 세션키의 연속적 사용 가능(재전송 공격) – 버전 5에서는 단 1회만 사용되는 서브 세션키 협약 가능 • 패스워드 공격 : 패스워드를 추측하는 공격이 가능 – 버전 5에서는 패스워드 추측 공격이 더 어렵도록 만듦(사전 인증 기 능) – 패스워드 공격을 완전히 막을 수는 없음 22

Kerberos Encryption Techniques 23 Fig. 4. 6 Generation of Encryption Key from Password Kerberos Encryption Techniques 23 Fig. 4. 6 Generation of Encryption Key from Password

PCBC Mode Used in Kerberos v 4, cf : Fig. 2. 9 24 PCBC Mode Used in Kerberos v 4, cf : Fig. 2. 9 24

Kerberos - in practice • • Currently have two Kerberos versions: 4 : restricted Kerberos - in practice • • Currently have two Kerberos versions: 4 : restricted to a single realm 5 : allows inter-realm authentication Kerberos v 5 is an Internet standard specified in RFC 1510, 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 (released 2003) – 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 25

- Key Management Public-Key Certificate Use 26 - Key Management Public-Key Certificate Use 26

X. 509 Authentication Service • part of CCITT X. 500 directory service standards – X. 509 Authentication Service • part of CCITT X. 500 directory service standards – distributed servers maintaining some user info database • defines framework for authentication services – directory may store public-key certificates – with public key of user – signed with private key by certification authority • also defines authentication protocols • uses public-key cryptography & digital signatures – algorithms not standardised, but RSA recommended • Used in a variety of contexts – S/MIME chapter 5 – IP secuirty chapter 6 – SSL/TLS, SET chapter 7 27

X. 509 Formats 28 X. 509 Formats 28

Typical Digital Signature Approach 29 Typical Digital Signature Approach 29

Obtaining a User’s Certificate • Characteristics of certificates generated by CA: – Any user Obtaining a User’s Certificate • Characteristics of certificates generated by CA: – Any user with access to the public key of the CA can verify the user public key that was certified. – No part other than the CA can modify the certificate without this being detected. 30

CA Hierarchy • If both users share a common CA then they are assumed 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 • User 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 31

X. 509 CA Hierarchy A can acquire the following certificates from directory to establish X. 509 CA Hierarchy A can acquire the following certificates from directory to establish a certificate path to B X<>W<>V<>Y<>Z<> To acquire A’s public key Z<>Y<>V<>W<>X<> Y<> = the certificate of user X issued by certification authority Y 32

Revocation of Certificates • Reasons for revocation: – The users secret key is assumed 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. • CA’s maintain list of revoked certificates – the Certificate Revocation List (CRL) • users should check certs with CA’s CRL 33

Authentication Procedures • X. 509 includes three alternative authentication procedures: • One-Way Authentication • Authentication Procedures • X. 509 includes three alternative authentication procedures: • One-Way Authentication • Two-Way Authentication • Three-Way Authentication • all use public-key signatures 34

Authentication Procedures t: time stamp r: nonce 35 Authentication Procedures t: time stamp r: nonce 35

One-Way Authentication • message ( A->B) used to establish – the identity of A One-Way Authentication • 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 36

Two-Way Authentication • 2 messages (A->B, B->A) which also establishes in addition: – the 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 37

Three-Way Authentication • 3 messages (A->B, B->A, A->B) which enables above authentication without synchronized 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 38

X. 509 Version 3 • has been recognised that additional information is needed in 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 39

Certificate Extensions • key and policy information – convey info about subject & issuer 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 40

PKIX of IETF PKI users Certificate/CRL Repository Certificate/CRL retrieval Registration Certificate authority publication Certificate/CRL PKIX of IETF PKI users Certificate/CRL Repository Certificate/CRL retrieval Registration Certificate authority publication Certificate/CRL publication CRL issuer End entity Registration, Initialization, Certification, Key pair recovery, Key pair update Revocation request Certificate authority Cross-certification Certificate authority PKI Management entities Figure 4. 7 PKIX Architectural Model 41

Recommended Reading and WEB Sites • www. whatis. com (search for kerberos) • Bryant, 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/ 42