Kerberos Protocol

%본 글은 https://en.m.wikipedia.org/wiki/Kerberos_(protocol) 의 내용 중 중요하다 생각되는 부분만 발번역, 의역을 한 것입니다. 틀린 부분은 지적 해주시면 수정 하겠습니다.

- Kerberos -

Kerberos는 Computer Network Authentication Protocol이다. Non-secure Network에서 Ticket을 기본으로 Node간의 communication을 중재한다. client-server간 Mutual Authentication을 목표로 디장인되었다. Kerberos의 Message는 Replay Attacks이나 Eavesdropping(도청감지)을 방어 할 수 있다.

Kerberos는 UPD, 88 Port를 사용하고 대칭 키 암호화 방식을 사용한다. Trusted한 3rd-party 간의 Federation을 위한 Protocol이다.

- Protocol -

Terms

AS : Authentication Server

KDC : Key Distribution Center

TGT : Ticket-Granting Ticket

TSG : Ticket-Granting Service

SS : Service Server

Sequence

1. User는 Client Machines에 userId 및 password를 입력한다. password 대신에 public key를 사용 할 수 있다.

2. Client는 password를 대칭키 암호로 사용을 한다. 

3. Client는 userId를 AS에 text message로 보낸다. AS는 자신의 DB에서 User의 Password를 찾는다. (User의 secret key나 password는 AS에 보내지지 않는다.)

4. AS는 아래 두 가지 Message들을 Client에 전송한다.

• Message A : Client의 secret Key(password)로 암호화 된 Client/TGS Session Key
• Message B : TGS의 secret키로 암호화된 Ticket-Granting-Ticket. (ClientID, network address, validity period, client/TGS session key 포함)

5. Client로 Message A,B가 전달되면 user의 password를 이용하여 Message A를 복호화 한다. 만약 AS DB에 저장된 User의 password와 일치 하지 않으면 Message A를 복호화 할 수 없다. 복호화가 성공되면 Client/TGS Session Key를 얻을 수 있다. Session Key는 TGS와 통신에 사용되며 Message B는 Client에 의해 복호화 할 필요가 없고 될 수도 없다. (TGS와 AS간 미리 Sharing된 대칭키로 암호화 되었기 때문)

6. Client는 아래의 Message를 TGS에 전송한다.

• Message C : Message B인 TGT와 사용할 Service의 ID
• Message D : Message A에서 추출된 Session Key로 암호화된 Authenticator (clientId, timestamp 포함)

7. TGS는 Message C와 D를 받으면 미리 AS와 공유된 TGS secret key를 이용하여 Message B를 Message C에서 추출한다. Message B에는 TGS Session Key가 포함되어 있기 때문에 Message D를 복호화 하여 Authenticator를 추출 할 수 있다. 그리고 아래 두가지 message를 Client로 보낸다.

• Message E : SS와 선 공유된 Service secret Key로 암호화된 Client-To-Server Ticket (ClientId, Client Network Address, validity period, client/Server Session Key 포함)
• Message F: Client/TGS Session Key로 암호화된 Client/Server Session Key

8.TGS로 부터 Message E,F를 받으면 Client는 SS에 인증 할 준비를 모두 마치게 된다. Client는 SS에 아래 두 가지 Messgae를 보낸다.

• Message E : 7단계의 Message E
• Message G : 새로운 Client/Server Session Key로 암호화된 새로운 Authenticator (Client Id, Timestamp 포함)

9. SS는 TGS와 선 공유된 secret key로 Client/Server Session Key를 Message E에서 추출한다. Client/Sever Session Key로 Message G에서 ClientId와 Timestamp를 추출한다. 그리고 아래 Message를 Client에 보낸다.

• Message H : Client/Server Session Key로 암호화 된 timestamp (version 4, 5에서는 필요하지 않다.)

10. Client 는 Client/Server Session Key를 이용하여 timestamp를 추출하고 confirm한다. 이제 client는 서버를 Trust할 수 있고 service request를 보낼 수 있다.

- Drawback과 Limitation -

• Single Point of failure : AS나 TGS나 하나의 서버가 죽으면 모든 유저는 서비스를 사용 할 수 없다.
• 시간에 매우 엄격하다 : NTP(Network Time Protocol)을 이용하여 서버간 시간을 맞추는 작업이 필요하다.
• 관리 Protocol이 표준화가 되지 않았다. 서버 구현에 따라 다르게 제공된다.
• 대칭 키 암호화를 선택한 경우 모든 키가 KDC에 의해 관리 되기 때문에 impersonate user attack이 가능하다 (?)
• 각 네트워크가 다른 Domain이 필요하기 때문에 hosting이나 cluster가 복잡해지게 된다.
• Trusted된 환경에서만 사용가능 하고 Untrusted된 Client의 경우 사용 될 수 없다.
• Trust Relationship문제로 Test 환경 구성이 어렵다.

- Appendix -

https://ko.wikipedia.org/wiki/%EC%BB%A4%EB%B2%A0%EB%A1%9C%EC%8A%A4

- 사족 -

IDP integration을 한 후 부쩍 표준 Authentication에 관심이 많아져 찾아 보았다. 개인적으로 AS가 사용자 password를 알고 있어야 한다는 것이 마음에 들진 않지만 Trusted 환경에서는 강력한 보안을 제공 할 수 있을 것 같다. 하지만 UnTrusted 환경에서 사용하지 못하니 사용해볼 기회는 없을 듯..