Skip to content

Kerberos authentication system

참조 : http://www.secureip.info/networksecurity/kerberos.htm

Security Services

Kerberos는 Network Authentication Protocol이다. 클라이언트와 서버가 있을 경우 중간에서 클라이언트의 Authentication 서비스를 해주는 것이 바로 Kerberos이다. Kerberos는 MIT 의 ATHENA 프로젝트에 의해 개발되었다.

아래에서는 Authentication 방법과 Kerberos 에 쓰이는 방식을 설명하였다. 순서대로 simple authentication 방법과 좀더 안전한 Authentication 방법 그리고 마지막으로 이러한 이론을 이용하여 Kerberos에서 어떻게 메시지들이 오가는지를 설명하였다.

Simple Authentication





먼저 간단한 인증 과정을 살펴 보자. 위에서 보면 C와 V가 있는데, C는 클라이언트를 나타내고 V는 서버를 일컫는 말이다. 그리고 또 하나 등장하는 것이 AS 인데, 여기서 AS(Authentication Server)는 중앙 DB에 모든 사용자들의 암호를 기억하고 있게 된다. 덧붙여 설명하자면 이 AS는 각 서버와 유일한 비밀 키를 공유하게 되는데, 이러한 키는 사전에 안전한 방법으로 분배되어 있어야 한다. 예를 들어 관리자가 직접 키를 디스켓에 담아가는 방식으로 말이다. 그럼 이것을 기본으로 위의 시나리오를 살펴보기로 하자.

  • 1단계 : 먼저 클라이언트는 AS에게 자신의 ID와 자신이 통신하고자 하는 서버의 ID, 그리고 사용자의 암호를 포함하는 메시지를 보낸다.

  • 2단계 :

그러면 AS는 보내온 사용자의 ID와 암호를 가지고 자신이 가지고 있는 DB에서 그것이 유효한지를 확인한다. 그리고 이 사용자가 통신하고자 하는 서버에 접근 권한을 가지고 있는지 또한 확인하게 된다. 이러한 과정을 거친 후에 사용자에게 인증되었다는 표시로 Ticket이라는 것을 보내주게 된다. 이 Ticket은 위에서도 보는 바와 같이 클라이언트 ID, 네트워크 주소, 서버의 ID 정보를 AS와 서버가 공유하고 있는 비밀 키를 이용하여 암호화 하여 클라이언트에게 전해진다.

  • 3단계 :

이 Ticket을 받은 클라이언트는 자신의 ID와 Ticket을 함께 서버에게 보내주게 된다. 이렇게 되면 서버는 Ticket이 자신의 비밀키로 암호화 되어 있기 때문에 그것을 복 호화 할 수 있다. 그리고 서버는 복 호화한 클라이언트의 ID와 그냥 날아온 클라이언트의 ID을 비교해 보고 그것이 같으면 서버는 이 사용자가 인증된 사용자라고 인식하게 되는 것이다.

-보안 측면

Ticket에 보면 네트워크 어드레스(ADC)가 있는데 그것은 공격자가 Ticket을 가지고 다른 워크스테이션에서 접근하는 것을 막기 위한 것이다. 메시지(2)에서 보면 AS 가 클라이언트에게 Ticket을 보내주는데 만약 그것을 공격자가 가로채어 다른 워크스테이션에서 그 Ticket을 가지고 클라이언트 ID을 이용하여 서버에 접근하고자 할 때, 서버는 네트워크 어드레스를 보고 이것이 맞는지 틀리는지를 확인하게 된다.

-단점

  1. 이 시나리오에서는 만약 어떤 사용자가 메일을 체크 하고자 할 때 계속해서 암호를 넣어주어야 하는 불편이 생긴다. 즉 한번 받은 Ticket을 재 사용 할 수 없다는 문제가 생기게 된다.

  2. 두 번째 문제점은 메시지 (1)에서 보듯이 암호가 그냥 일반 텍스트로 전송이 된다는 것이다. 이렇게 되면 공격자가 이 정보를 가로채어 이용할 수 있는 여지를 남기게 된다.

A more secure Authentication Dialogue

위와 같은 문제점들을 해결하고자 나온 것이 아래와 같은 시나리오이다. 첫 번째 시나리오와 틀려진 점이라면 바로 TGS (Ticket Granting Server)을 두었다는 것이다. 이 시나리오에서는 AS는 단순히 인증만을 담당하게 되고 Ticket을 발급해 주는 것은 TGS가 맡게 되는 것이다. 여기서 TGS는 AS에서 인증 받은 클라이언트에게만 Ticket을 발급하게 된다.

Once per user logon session:


– 1단계 :

사용자는 자신의 ID와 TGS ID를 TGS 서비스 요청을 위해 함께 AS 에게 전송한다.

  • 2단계 :

사용자의 암호를 이용하여 생성한 키를 이용하여 Ticket 을 암호화(Encryption)하여 클라이언트에게 전송한다. 이것을 받은 사용자는 역시 마찬가지로 자신의 암호(Password)를 이용하여 키를 생성하여 날아온 Packet을 풀어(Decryption) Ticket을 얻는다.

Ticket에 보면 Ticket이 만들어진 날짜와 시간정보를 포함하는 Timestamp 값이 들어가는데, 그것은 어떤 공격자가 Ticket을 캡쳐하여 이용하려는 것을 막기 위함이다. 그리고 Ticket-granting ticket은 AS와 TGS가 공유하고 있는 비밀키로 암호화 되어 있기 Ticket의 번 갈음(alternation)을 막을 수 있다. 그리고 다시 Ticket 은 사용자의 암호(password)로 암호화(encryption)되어 있기 때문에 승인된 사용자만이 쓸 수 있게 된다(Authentication 역할).

Once per type of service :


– 3 단계 :

여기서는 클라이언트가 service-granting ticket을 요구한다. 이때 사용자는 자신의 ID와 접속하고자 하는 서버의 ID을 전송하게 된다.

  • 4 단계 :

이 때, TGS는 들어오는 Ticket을 Decryption하고 그 안에 들어있는 자신의 ID을 확인한다. 이 절차가 끝나면, TGS는 lifetime의 기한이 만료되었는지를 체크 한다. 그리고 나서 사용자를 인증하기 위해 Ticket안에 있는 사용자 ID와 네트워크 어드레스를, 같이 전송되어온 사용자의 ID와 네트워크 어드레스와 비교한다. 여기서 사용자가 인증되면 service-granting ticket을 전송하여 준다.

여기서 전송되어지는 service-granting ticket은 TGS와 서버가 공유하고 있는 비밀키로 암호화 하여 전송되어진다.

Once per service session :

그리고 마지막으로 5단계에서는 클라이언트의 ID와 service-granting ticket을 가지고 사용자를 인증하게 된다.

Kerberos Version 4 Message Exchange

위와 같은 원리를 이용하여 kerberos는 아래와 같은 메시지를 주고 받으면서 동작한다.

(a) Authentication Service Exchange : To Obtain Ticket-Granting Ticket



앞서와 달리 여기서 추가된 것은 1단계에서는 Timestamp가 추가되어 시간에 따른 확인이 가능하게 하였고, 2단계에서는 사용자의 ID와 네트워크 어드레스 그리고 TGS의 ID 또한 Timestamp와 lifetime이 추가되었다. 그리고 클라이언트와 TGS가 공통으로 쓸 비밀키도 이때 전송되어 진다. 이것은 이 키를 사용하는 사람이 C라는 것을 나타내게 되는 것이다.

(b) Ticket-Granting Service Exchange : To Obtain Service-Granting Ticket




여기서 추가된 것은 3단계에서 Authenticator 정보가 추가 되었는데 이 Authenticator 안에 들어있는 정보와 Ticket안에 들어있는 정보를 비교하여 사용자를 인증하는 역할을 하게 된다. 4단계에서는 이렇게 인증된 사용자에게 service-granting ticket을 넘겨주게 되는데, 이때 클라이언트와 TGS가 공유하고 있는 비밀 키를 이용하여 암호화(Encryption)해서 전송하여 준다.

(c) Client/Server Authentication Exchange : To Obtain Service




마지막으로 클라이언트는 받은 service-granting ticket과 Authenticator을 같이 접속하고자 하는 서버에게 전송하게 되고 이것을 가지고 서버는 이 사용자가 인증 받은 사용자인지를 판단하게 된다.

Published inLinux