[SASL] Kerberos Basics

Kerberos Basics

Kerberos는 기존의 공유 비밀 키 암호화를 사용하여 신뢰할 수 있는 제3자 인증 서비스로서 인증을 수행한다. Kerberos는 호스트 운영 체제의 인증에 의존하지 않고, 호스트 주소에 대한 신뢰를 기반으로 하지 않으며, 네트워크의 모든 호스트의 물리적 보안을 요구하지 않고, 네트워크를 통해 이동하는 패킷이 읽히고, 수정되고, 삽입될 수 있다는 가정 하에 주체의 신원을 확인하는 수단을 제공한다.

 

자격 증명을 얻는 두가지 방법인 초기 티켓 교환과 티켓-그랜팅-티켓(TGT) 교환은 약간 다른 프로토콜을 사용하며 다른 응용 프로그래밍 인터페이스(API) 루틴을 필요로 한다.

 

응용 프로그램 프로그래머가 보는 기본적인 차이점은 초기 티켓 교환은 티켓-그랜팅-티켓(TGT)을 필요로 하지 않지만 클라이언트의 비밀 키를 필요로 한다는 것이다.

 - 일반적으로 초기 티켓 교환은 TGT을 위한 것이며, 이후에는 TGT 교환이 사용된다.

 - TGT 교환에서는 TGT가 티켓 요청의 일부로 전송되며, 응답은 TGT에서 얻은 세션 키로 암호화된다. 

 - 따라서 사용자의 비밀번호는 초기 TGT를 얻기 위해 사용된 후 추가 티켓을 얻기 위한 후속 TGT 교환에서는 필요하지 않는다.

 

티켓-그랜팅-티켓은 서버 이름으로 Kerberos 서버(krbtgt/realm)를 포함한다. 서비스 티켓은 서버 이름으로 응용프로그램 서버를 포함한다. 티켓-그랜팅-티켓은 서비스 티켓을 얻기 위해 사용된다. 다른 realm의 서버에 대한 서비스 티켓을 얻기 위해서는 응용 프로그램이 먼저 해당 realm의 Kerberos 서버에 대한 티켓-그랜팅-티켓을 얻어야 한다.

 

Kerberos 서버의 응답은 티켓과 세션 키로 구성되며, 이는 사용자의 비밀 키 또는 TGT 세션 키로 암호화된다. 티켓과 세션 키의 조합은 자격 증명 세트로 알려져 있다. 응용 프로그램 클라이언트는 이 자격 증명을 사용하여 티켓과 인증자를 서버에 전송함으로써 응용 프로그램 서버에 인증할 수 있다. 인증자는 티켓의 세션 키로 암호화되며 클라이언트의 이름, 서버의 이름 및 인증자가 생성된 시간을 포함한다.

 

인증을 확인하기 위해 응용 프로그램 서버는 응용 프로그램 서버와 Kerberos 서버만 알고 있는 서비스 키를 사용하여 티켓을 해독한다. 티켓 내부에는 Kerberos 서버가 클라이언트의 이름, 서버의 이름, 티켓과 관련된 세션키 및 추가 정보를 포함시켰다.

 

응용프로그램 서버는 티켓 세션 키를 사용하여 인증자를 해독하고 인증자 정보가 티켓 정보와 일치하는지 확인한다. 서버는 또한 인증자 타임스탬프가 최근인지 확인하여 재생 공격을 방지한다(기본값은 5분). 세션 키는 Kerberos 서버에 의해 무작위로 생성되고 서비스 키와 사용자만 알고 있는 키로 암호화되어 전달되므로, 응용 프로그램 서버는 사용자가 올바른 키로 인증자를 암호화할 수 있었기 때문에 사용자가 실제로 주장하는 사람임을 확신할 수 있다.

 

재생 공격 및 메시지 스트림 수정 공격을 감지하기 위해, 주체 간에 교환되는 모든 메시지의 무결성은 세션 키로 키된 클라이언트 메시지의 충돌방지 체크섬을 생성하고 전송함으로써 보장될 수 있다. 주체 간에 교환되는 메시지의 프라이버시와 무결성은 세션 키를 사용하여 전달할 데이터를 암호화함으로써 보안이 유지될 수 있다.

Realms의 목적

Kerberos 프로토콜은 조직 경계를 넘어 작동하도록 설계되었다. Kerberos 서버를 운영하려는 각 조직은 자체 realm을 설정한다. 클라이언트가 등록된 realm의 이름은 클라이언트 이름의 일부이며, 응용 프로그램 서버는 이를 사용하여 요청을 수락할지 여부를 결정할 수 있다.

 

구 realm의 관리자가 상호 realm 키를 설정하면, 한 realm에서 인증된 클라이언트가 다른 realm에서 자격증명을 사용할 수 있게 된다. 상호 realm 키의 교환은 각 realm의 티켓-그랜팅 서비스가 다른 realm에서 주체로 등록되도록 한다. 그런다음 클라이언트는 로컬 티켓-그랜팅 서비스에서 원격 realm의 티켓-그랜팅 서비스에 대한 티켓-그랜팅-티켓(TGT)를 얻을 수 있다. 원격 realm의 서비스에 발급된 티켓은 클라이언트가 다른 realm에서 인증되었음을 나타낸다.

 

이 방법은 여러 realm에 걸쳐 조직 전체에서 인증을 수행하기 위해 반복될 수 있다. 먼 realm으로의 유효한 인증 경로를 구축하려면 로컬 realm이 대상 realm 또는 대상 realm과 통신하는 중간 realm과 상호 realm 키를 공유해야 한다.

 

realm은 일반적으로 계층적으로 조직된다. 각 realm은 부모와 키를 공유하고 각 자식과는 다른 키를 공유한다. 두 realm이 직접 상호 realm 키를 공유하지 않는 경우, 계층적 조직을 통해 인증 경로를 쉽게 구성할 수 있다. 계층적 조직이 사용되지 않는 경우, realm 간의 인증 경로를 구성하기 위해 일부 데이터베이스를 참조해야 할 수도 있다. 

 

realm은 일반적으로 계층적이지만, 대체 인증 경로를 통해 중간 realm을 우회하여 상호 realm 인증을 수행할 수 있다. 최종 서비스가 인증 프로세스에 얼마나 신뢰를 둘지 결정할때, 어떤 realm이 통과되었는지 아는 것이 중요하다. 이 결정을 용이하게 하기 위해 각 티켓의 필드에는 클라이언트를 인증하는 데 관여한 realm의 이름이 포함된다.

환경에 대한 가정

Kerberos는 보안 조치를 설계할 때 염두에 두어야 할 몇가지 제한사항이 있다:

 

1. 서비스 거부(DoS) 공격에 대한 대응 부족:

   Kerberos는 서비스 거부(DoS) 공격을 해결하지 않는다. 이 프로토콜의 특정 부분에서는 침입자가 응용 프로그램이 올바른 인증 단계를 수행하지 못하도록 방해할 수 있다. 이러한 공격(일부는 시스템의 '일반적인' 실패 모드로 보일 수 있음)의 탐지 및 해결은 자동화하지 않고 관리자 어드민에게 맡기는 것이 좋다.

2. 비밀 키의 보안 유지:

  주체는 자신의 비밀 키로 비밀을 유지해야 한다. 만약 침입자가 주체의 키를 탈취하면, 그 침입자는 해당 주체로 가장하거나 합법적인 주체에게 어떤 서버로도 가장할 수 있다.

3. 비밀번호 추측 공격에 대한 대응 부족:

  Kerberos는 '비밀번호 추측' 공격을 해결하지 않는다. 사용자가 약한 비밀번호를 선택하면, 공격자는 사용자의 비밀번호에서 파생된 키로 암호화된 메시지를 반복적으로 해독하려 시도하여 오프라인 사전 공격을 성공적으로 수행할 수 있다.

 

이러한 제한 사항을 고려하여 Kerberos를 사용하는 환경에서는 추가적인 보안 조치를 마련하는 것이 중요하다.

---

Using Kerberos files

Kerberos 런타임은 처리 과정에서 세가지 유형의 파일을 사용한다: 자격 증명 캐시, 재생 캐시, 그리고 키 테이블. 각 파일 유형은 파일을 관리하고 조작하기 위한 일련의 API 루틴을 가지고 있다.

Credentials Cache

자격 증명 캐시는 Kerberos 자격 증명(티켓, 세션 키 및 기타 식별 정보)를 반영구적인 저장소에 보관한다. Kerberos 런타임은 필요할때 캐시에서 자격 증명을 읽고, 새로운 자격 증명을 얻을때 캐시에 저장하낟. 이렇게 하면 응용프로그램이 자격 증명을 직접 관리할 필요가 없다.

 

Kerberos는 세가지 유형의 자격 증명 캐시를 지원한다: File, Memory, XMem. 기본 자격 증명 캐시 유형은 FILE이다. FILE 자격 증명 캐시는 HFS 파일에 유지되며 응용 프로그램 간에 공유될 수 있다. 자격 증명 캐시 파일은 /var/skrb/creds에 위치한다. 이 디렉토리는 sysplex의 여러 시스템에서 공유될 수 있다(Kerberos는 자격 증명 캐시 파일에 대한 접근을 직렬화하기 위해 글로벌 리소스 직렬화를 사용한다). 새로운 자격 증명 캐시 파일이 생성될 때마다 고유한 파일 이름이 생성된다. 이러한 자격 증명 캐시 파일은 삭제될 때까지 지속된다(kinit 명령은 새로운 기본 자격 증명 캐시를 생성할 때 사용자의 현재 기본 자격 증명 캐시 파일을 삭제한다). kdstroy 명령의 -e 옵션을 사용하여 만료된 자격 증명 캐시 파일을 제거할 수 있다. MEMORY 자격 증명 캐시는 저장소에 유지되며 이를 생성한 응용 프로그램만 접근할 수 있다. 응용 프로그램이 종료되면 자격 증명 캐시는 지속되지 않는다. XMEM 자격 증명 캐시는 Kerberos 보안 서버에 의해 데이터 공간에 유지된다. 자격 증명 캐시는 sysplex의 모든 시스템에서 읽을 수 있지만, 이를 생성한 시스템에서만 업데이트할 수 있다. Kerberos 보안 서버가 종료되면 자격 증명 캐시는 지속되지 않는다. Kerberos 보안 서버는 만료된 자격 증명만 포함된 자격 증명 캐시를 주기적으로 삭제한다. MODIFY SKRKDC, DISPLAY CREDS 명령을 사용하여 자격 증명 데이터 공간의 현재 내용을 표시할 수 있다.

Replay Cache

재생 캐시는 중복 요청을 감지하는데 사용된다. Kerberos 런타임이 요청을 처리할 때매다 재생 캐시에 항목이 추가된다. 나중에 처리된 요청이 이미 재생 캐시에 있는 항목과 일치하면 응용프로그램에 오류가 반환된다. 재생 캐시는 주기적으로 정리되어 오래된 항목을 제거한다(오래된 항목은 관련 요청의 수명이 만료된 경우 발생한다).

 

Kerberos는 두가지 유형의 재생 캐시를 지원한다: dfl과 mem. dfl 재생 캐시는 파일에 유지되며 응용 프로그램이 재시작된 후에도 지속된다. mem 재생 캐시는 메모리에 유지되며 응용 프로그램이 종료된 후에는 존재하지 않는다. 재생 캐시는 응용 프로그램 간에 공유해서는 안된다. 이는 동일한 타임스탬프를 가진 다른 요청으로 인해 잘못된 재생 오류가 발생할 수 있기 때문이다.

 

use_dvipa_override 구성 옵션이 1로 설정되면 주체가 sysplex 전반의 응용 프로그램에 의해 공유될 수 있다. 이는 재생 캐시도 sysplex 전반에 걸쳐 공유되어야 함을 의미하지만, 언급된 재생 캐시는 공유될 수 없다. 따라서 use_dvipa_override 구성 옵션이 1로 설정되면 선택된 또는 기본 재생 캐시는 SKRBKDC 시작 작업에 의해 제어되는 것으로 대체된다. 이는 Kerberized 응용 프로그램이 실행되는 모든 이미지에서 SKRBKDC 시작 작업이 실행 중이어야 함을 요구한다. 그렇지 않으면 use_dvipa_override 구성 옵션이 다시 0으로 설정된다.

Key table

키 테이블은 암호화 키를 저장하는데 사용된다. 이는 일반적으로 서버 응용 프로그램이 클라이언트 응용 프로그램으로부터 받은 요청을 해독할 때 Kerberos 런타임에서 사용할 암호화키를 제공하기 위해 사용된다. 각 키에는 관련된 버전 번호가 있으며, 키가 변경될 때마다 버전이 증가한다. 키 배포 센터(KDC)가 서비스 티켓을 암호화할 때, Kerberos 데이터베이스에 저장된 최신 암호화 키를 사용하고 티켓에 키 버전 번호를 기록한다. 그런 다음 티켓이 서버에 제시될 때, 키 버전 번호를 사용하여 키 테이블에서 적절한 키를 검색한다. 이를 통해 서버는 기존 티켓을 무효화하지 않고도 키를 변경할 수 있다.

 

Kerberos는 두가지 유형의 키 테이블을 지원한다. FILE과 WRFILE. 이 두 키 테이블 유형은 동일한 파일 기반 키 테이블을 참조한다. 차이점은 FILE로 열린 키 테이블은 읽기 전용인 반면, WRFILE로 열린 키 테이블은 읽기 및 쓰기가 가능하다는 점이다. 키 테이블은 여러 응용 프로그램이 공유할 수 있다.

---

Kerberos 서비스 사용

"krb5_context" 불투명 데이터 타입은 현재 Kerberos 컨텍스트를 나타낸다. 각 응용 프로그램은 최소한 하나의 Kerberos 컨텍스트를 가져야 한다. Kerberos 컨텍스트는 Kerberos 구성 파일에서 얻은 구성 데이터와 응용 프로그램에 의해 설정된 재정의 값을 포함한다. 하나의 Kerberos 컨텍스트는 동일한 프로세스 내의 여러 스레드에서 공유될 수 있지만, 프로세스 간에는 공유될 수 없다. "krb5_init_context()" API 루틴은 Kerberos 컨텍스트를 생성하는데 사용된다.

 

"krb5_auth_context" 불투명 데이터 타입은 Kerberos 인증 컨텍스트를 나타낸다. Kerberos 인증 컨텍스트는 메시지 서비스 루틴에서 사용된다. 각 클라이언트-서버 연결은 자체 인증 컨텍스트를 가져야 한다. 왜냐하면 시쿼스 번호, 암호화 키, 체크섬 및 인증자가 컨텍스트에 저장되기 때문이다. 인증 컨텍스트가 스레드 간에 공유되는 경우, 응용 프로그램은 컨텍스트가 동시에 여러 스레드에 의해 접근되지 않도록 동시성 제어를 제공해야 한다. "krb5_auth_con_init()" API 루틴은 Kerberos 인증 컨텍스트를 생성하는데 사용된다.

 

코드 페이지를 올바르게 처리하려면, Kerbros API 루틴이 호출되기 전에 'setlocale()' 루틴을 호출해야 한다. 이는 올바른 코드 페이지가 설정되도록 보장한다. Kerberos는 더블 바이트 또는 양방향 문자 세트를 지원하지 않는다. 또한 주체와 realm 이름은 POSIX 문자 세트의 문자로 구성되는 것이 강력히 권장된다. POSIX 기반 휴대용 문자 세트에 대한 표는 POSIX 문자 세트를 참조하세요.

 

Kerberos API는 자체 신호 핸들러를 설정하지 않는다. 이는 응용 프로그램의 신호 사용과 충돌할 수 있기 때문이다(신호 핸들러는 프로세스 전체 범위를 가진다). 따라서 응용 프로그램은 SIGPIPE 신호에 대한 자체 신호 핸들러를 설정해야 한다. 액션 루틴은 응용 프로그램이 파이프 깨짐에 대한 자체 처리를 수행할 필요가 없는한 "SIG_IGN"일 수 있다.