Kerberos

신뢰할 수 있는 제3자(KDC)가 발급하는 암호화된 '티켓'을 이용해, 비밀번호를 네트워크에 반복해서 흘리지 않고도 사용자·서비스가 서로를 인증하는 네트워크 인증 프로토콜이다.

MIT에서 만들어졌고, 이름은 그리스 신화의 지옥문을 지키는 머리 셋 달린 개 케르베로스에서 왔다. 머리 셋은 인증에 관여하는 세 주체 — 클라이언트, 서버, KDC — 를 상징한다. 오늘날 Active Directory의 기본 인증 방식이며, 리눅스/유닉스 환경에서도 널리 쓰인다.

핵심 아이디어는 단순하다. 매번 각 서버에 비밀번호를 보내 로그인하는 대신, 신뢰받는 중앙 기관(KDC)에서 딱 한 번 신원을 증명하고 티켓을 받아, 이후에는 그 티켓을 제시해 여러 서비스에 접근한다.

왜 필요한가

초창기 네트워크 인증은 서버마다 비밀번호를 그대로 주고받는 방식이 많았다. 이는 여러 문제를 낳는다.

도청: 평문 비밀번호가 네트워크를 오가면 스니핑으로 탈취된다
반복 노출: 서비스마다 로그인하면 비밀번호가 계속 네트워크에 노출된다
서버 신뢰 문제: 사용자만 인증하고 서버는 검증하지 않으면 가짜 서버에 속을 수 있다

Kerberos는 이를 다음으로 해결한다.

비밀번호 자체를 네트워크로 전송하지 않는다 (비밀번호에서 파생한 키로 암호화만 함)
한 번 인증하면 티켓을 재사용해 SSO(Single Sign-On) 를 구현한다
상호 인증(mutual authentication) 을 지원해 클라이언트뿐 아니라 서버의 진위도 확인한다

구성 요소

구성 요소	역할
KDC (Key Distribution Center)	인증의 중심. 아래 AS와 TGS를 포함한다. AD에서는 도메인 컨트롤러가 KDC 역할을 한다
AS (Authentication Server)	최초 로그인 시 사용자 신원을 확인하고 TGT를 발급
TGS (Ticket Granting Server)	TGT를 제시받아 각 서비스용 서비스 티켓을 발급
Principal	인증 대상의 고유 이름 (사용자나 서비스, 예: `alice@EXAMPLE.COM`)
Realm	Kerberos의 관리 영역. 관례상 대문자 도메인명 (예: `EXAMPLE.COM`). AD의 도메인에 대응
TGT (Ticket Granting Ticket)	"이 사용자는 인증됨"을 증명하는 초기 티켓. 이후 서비스 티켓을 받을 때 사용
Service Ticket	특정 서비스(파일서버 등)에 접근할 때 제시하는 티켓

동작 원리

Kerberos 인증은 크게 세 단계로 나뉜다. 각 단계는 AS 교환 → TGS 교환 → 클라이언트/서버 교환이다.

[클라이언트]                         [KDC]                       [서비스 서버]
                           ┌── AS ──┬── TGS ──┐
     │                     │        │         │                    │
 ① AS-REQ (사용자 식별)      │        │         │                    │
     │ ─────────────────▶  │ AS     │         │                    │
     │                     │ 신원확인, TGT 생성  │                    │
 ② AS-REP (TGT + 세션키)    │        │         │                    │
     │ ◀─────────────────  │        │         │                    │
     │                                                             │
 ③ TGS-REQ (TGT + "파일서버 티켓 줘")                                 │
     │ ───────────────────────────▶ │ TGS     │                    │
     │                              │ TGT 검증, 서비스 티켓 생성        │
 ④ TGS-REP (서비스 티켓 + 세션키)       │         │                    │
     │ ◀─────────────────────────── │         │                    │
     │                                                             │
 ⑤ AP-REQ (서비스 티켓 + Authenticator)                              │
     │ ─────────────────────────────────────────────────────────▶  │
     │                                               티켓 검증, (선택) 서버 인증
 ⑥ AP-REP (상호 인증 시)                                             │
     │ ◀─────────────────────────────────────────────────────────  │
                                                                접근 허용

AS 교환 (로그인): 클라이언트가 사용자 principal을 담아 AS에 요청하면, AS는 비밀번호에서 파생한 키로 암호화한 세션 키와 TGT를 응답한다. 비밀번호를 아는 사용자만 세션 키를 복호화할 수 있으므로, 비밀번호를 네트워크로 보내지 않고도 인증된다.
TGS 교환: 클라이언트가 TGT를 제시하며 "파일서버에 접근할 티켓을 달라"고 요청하면, TGS는 TGT를 검증하고 해당 서비스용 서비스 티켓을 발급한다.
클라이언트/서버 교환: 클라이언트가 서비스 티켓과 Authenticator(타임스탬프 포함)를 서버에 제시한다. 서버는 자신의 키로 티켓을 열어 검증하고 접근을 허용한다. 필요하면 서버도 응답을 보내 자신을 증명한다(상호 인증).

핵심 포인트

비밀번호는 절대 전송되지 않는다. 비밀번호로 만든 키로 복호화 가능 여부만 확인한다
타임스탬프를 써서 재전송 공격(replay)을 막는다. 그래서 클라이언트·서버·KDC의 시간 동기화(NTP) 가 필수다 (기본 허용 오차 5분)
TGT 덕분에 세션 동안 비밀번호를 다시 입력하지 않아도 여러 서비스에 접근할 수 있다 (SSO)

Active Directory와의 관계

Windows 도메인 환경에서 Kerberos는 Active Directory의 기본 인증 프로토콜이다.

도메인 컨트롤러(DC) 가 KDC 역할을 수행한다
AD 도메인 이 Kerberos Realm 에 대응한다
사용자가 도메인에 로그인하면 DC에서 TGT를 받고, 파일 공유·Exchange·SQL 등에 접근할 때 서비스 티켓을 받아 쓴다
구형 호환을 위해 NTLM도 남아 있지만 취약점이 많아 신규 사용은 지양된다