Authentication Applications Chapter 4 Authentication Applications

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

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)

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

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.

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

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

A Simple Authentication Dialogue C  AS: IDc || Pc || IDv AS  C: Ticket C  V: IDc || Ticket Ticket = EKv[IDc || Pc || IDv]

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

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

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

Version 4 Authentication Dialogue Authentication Service Exhange: To obtain Ticket-Granting Ticket C  AS: IDc || IDtgs ||TS1 AS  C: EKc [Kc,tgs|| IDtgs || TS2 || Lifetime2 || Tickettgs] Ticket-Granting Service Echange: To obtain Service-Granting Ticket (3) C  TGS: IDv ||Tickettgs ||IDc (4) TGS  C: EKc [Kc,¨v|| IDv || TS4 || Ticketv] Client/Server Authentication Exhange: To Obtain Service (5) C  V: Ticketv ||IDc (6) V  C: EKc,v[TS5 +1]

Overview of Kerberos

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

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

Request for Service in Another Realm(V.5)

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

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

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

Kerberos Encryption Techniques Fig. 4.6 Generation of Encryption Key from Password

PCBC Mode

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

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 cryptogrraphy & 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

X.509 Formats

Typical Digital Signature Approach

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.

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

X.509 CA Hierarchy

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

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

Authentication Procedures

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

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

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

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

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/