Kerberos 4

커버로스 4는 내부 암호로 DES를 사용하며, 설명을 위해 Athena 프로젝트의 Bill Bryant가 사용한 방법으로 구조 설명을 하겠다

단순 인증 절차 : 인증서버(AS:authentication server)

AS는 각 서버와 유일한 비밀 키를 공유한다
이 때 비밀 키는 물리적으로 분배되거나 다른 안전한 방법을 통해서 분배 된다.

아래의 가상 절차를 고려해보자

• (1) 사용자가 워크스테이션에 로그온하고, 서버 V에 접근 요청
  • 사용자 워크 스테이션 내 클라이언트 모듈 C는 사용자 패스워드 요구
  • 사용자의 ID와 서버 ID 그리고 사용자 패스워드를 포함하는 메시지를 AS에 보낸다
• (2) AS의 티켓 발행
  • AS는 데이터베이스 조회
    • 사용자가 자신의 ID와 일치하는 패숴워드를 입력했는지
    • 서버 V에 접근 허가가 있는지
  • 데이터 베이스 조회(검사)를 통과하면, 티켓을 발행한다
    • 클라이언트가 접근하려는 서버에게 이 사용자가 적법함을 알려줘야 함
    • 해당 티켓은 AS와 서버가 공유하고 있는 비밀키로 암호화 된다
      • 사용자 ID, 네트워크 주소, 서버 ID를 포함해서 생성
      • 서버 ID가 있어서 서버는 그 티켓이 올바르게 복호화 되었음을 확인
      • **IDc가 있어서 티켓이 C에게 발행 되었음이 자명)
      • **ADc가 있어서 티켓을 요청한 워크스테이션에서만 티켓을 사용할 수 있도록 함
• (3) C의 V 접근 요청
  • C는 AS에게 받은 티켓으로 V에 접근 요청을 한다.
    • 이 때 C의 ID와 티켓을 함께 제공한다.
  • V는 티켓을 복호화 하고, 티켓 속 사용자 ID와 C의 ID가 일치하는지 확인한다
    • 일치하면 서비스 제공

좀 더 안전한 인증 절차 : 아직 나약하다

개방 된 네트워크 환경에서 어느 정도 인증 문제는 해결 되었지만, 아직 해결해야 할 문제가 남아있다.

• 입력패스워드 수 과다
  • 서버 접속 마다 매번 패스워드 입력
  • 해결방법: 티켓 재사용
  • 문제는 다른 서버 접속 시 패스워드 입력
• 패스워드를 평문으로 전송
  • 도청 가능
  • 해결방법: 티켓발행서버(TGS: Ticket-Granting Server) 도입

가능한 공격 시나리오가 또한 몇가지가 있다.

• 티켓을 가로챈 뒤 해당 사용자가 워크 스테이션에서 로그오프 할 때까지 대기
• 공격자는 자신의 워크스테이션 주소를 조작해서, 공격 대상 컴퓨터와 동일 주소를 갖도록 조작
• 티켓을 재상요하여 TGS를 속인다.

대비책은 티켓 안에 타임 스탬프(티켓 발행 시점, 티켓 유효기간)을 포함하면 된다.

개선 된 절차는 아래와 같다

• 사용자 로그온 세션 마다 한번 (로그인 과정이라 생각하면 편하다!)
  

클라이언트는 사용자 ID를 AS에 보내어 티켓-승인 티켓을 요청한다
클라이언트는 이 때 TGS 서비스 사용 요청도 해야 하므로 TGS ID도 함께 보낸다

AS는 사용자 패스워드로부터 얻은 키를 이용해 암호화한 티켓을 클라이언트에게 보낸다
이 티켓을 받은 클라이언트는 사용자에게 패스워드 입력을 요구하고 키를 생성 하고, 들어오는 메시지를 복호화 한다.
적법한 패스워드를 입력 받으면 티켓을 성공적으로 얻을 수 있다.

결론적으로 패스워드를 평문 형태로 전송하지 않고, 문제를 해결 하였다.

• 서비스 유형마다 한 번
  
  클라이언트는 사용자를 대신해서 서비스-승인 티켓을 요청한다.
  이를 위해 클라이언트는 사용자 ID, 요청 되는 서비스 ID, 티켓-승인 티켓을 포함하는 메시지를 TGS에 보낸다

TGS는 수신한 티켓을 복호화 하고, 자신의 ID가 존재함을 보고 복호화가 제대로 되었음을 알게 된다
유효기간 만료 여부 확인도 한다.
사용자 인증을 위해 사용자 ID와 네트워크 주소를 입력되는 정보와 비교한다.
만일 사용자가 V에 접속이 허락된 상태라면 TGS는 요청된 서비스에 접근을 허락하도록 티켓을 발행한다

• 서비스 세션마다 한번
  • 
    
    클라이언트는 사용자를 대신해 서비스 접근을 요구한다.
    이를 위해 클라이언트는 사용자 ID와 서비스-승인 티켓을 포함하는 메시지를 서버에 보낸다
    서버는 티켓의 내용을 확인해서 인증한다.

개선된 가상 절차의 문제점 (개념 보충 필요)

• 티켓-승인 티켓의 유효기간 없음
  • 티켓-승인 티켓 유효기간 문제
  • 서비스-승인 티켓 유효기간 문제
• 서버를 사용자에게 인증하는 절차가 없음

더더욱 개선하는 방법은 아래와 같다

• 인증 서비스 교환 : 티켓-발행 티켓 취득
  • 
• 티켓-발행 서비스 교환 : 서비스 발행 티켓 취득
  • 
• 클라이언트/서버 인증 교환 : 서비스 취득
  • 
    커버로스 개요도를 나타내면 아래와 같다
    
    

커버로스 공동체와 다중 Kerberi

커벌초스 서버, 다수의 클라이언트 다수의 응용 서버로 구성된 완전한 커버로스 환경을 위해서는 다음과 같은 조건이 필요하다

1. 커버로스 서버는 반드시 ID와 모든 사용자의 해시 된 패스워드를 데이터베이스에 저장하고 있어야 한다.
   • 모든 사용자는 커버로스 서버ㅑ에 등록해야 한다
2. 커버로스 서버는 필히 각 서버와 비밀 키를 공유해야 한다.
   • 모든 서버는 커버로스 서버에 등록 해야 한다
     위와 같은 환경을 커버로스 공동체라고 부르기도 한다.

공동체의 개념은 다음과 같이 설명 할 수 있다.

• 동일한 커버로스 데이터베이스를 공유하며 관리 대상이 되는 노드의 집합이다
• 커버로스 데이터베이스는 커버로스 마스터 컴퓨터 시스템에 들어있는데, 이 시스템은 물리적으로 안정한 장소에 위치하도록 해야만 한다.
• 일긱만 가능한 커버로스 데이터베이스 복사본을 다른 커버로스 컴퓨터 시스템에 둘 수 있다
  • 하지만, 데이터베이스 컨텐츠를 변경하거나 접근하려면 반드시 커버로스 마스터 패스워드를 알고 있어야 한다.
• 커버로스 주체
  • 커버로스 시스템 내에서 주체 이름에 의해 식별 된다.
  • 서비스나 사용자 이름, 인스턴스 이름, 공동체 이름

다른 관리 조직 하에 있는 클라이언트와 서버의 네트워크는 서로 다른 공동체를 갖고 있다.

• 즉 한 관리 영역에 있는 사용자 서버를 다른 곳에 있는 커버로스 서버ㅑ에 등록하라고 하는 것을 일반적으로 실현하기 어렵고, 관리 정책과도 맞지 않다.
• 한 공동체의 사용자가 다른 공동체에 속한 서버로부터 서비스를 받기 위해 접근할 필요가 있을 수도 있고, 어떤 서버는 다른 공동체에 속한 사용자를 인증 할 수 있다면 그들에게도 서비스를 제공해야 할지 모른다.