요약

  • RFC 1510은 1993년 9월 Realm 간 키와 티켓 발급 티켓(TGT)으로 Kerberos Realm을 연결했다. transited는 순서가 없는 중간 Realm의 집합이며, 사용자 Realm과 서비스 Realm은 티켓의 다른 필드에 기록된다.
  • 두 Realm을 직접 잇는 한 홉 경로에서는 transited가 비어도 인증이 경계를 넘을 수 있다. RFC 1510을 2005년에 대체한 RFC 4120은 경로 검사를 명시했다. 애플리케이션 서버가 직접 확인하거나 KDC 정책 검사 표시가 없는 Realm 간 티켓을 거부해야 한다.

분석

두 끝은 그 목록 바깥에 있다

설명용 Realm 이름을 두자. ALPHA.EXAMPLE에 등록된 사용자가 BETA.EXAMPLE의 파일 서비스 티켓을 요청한다. 두 Realm이 필요한 Realm 간 키를 공유하고 그 사이에 제3의 Realm이 없다면 transited 필드는 비어 있을 수 있다. 양 끝은 티켓의 다른 필드가 식별하며, 빈 값은 중간 Realm이 없는 직접 경로를 기록한다.

transited에는 중간 Realm이 간단히 기록된다. 양 끝은 다른 필드에 있고, 직접 연결에는 중간 항목이 없다.

RFC 1510은 Realm을 자체 Kerberos 서비스를 운영하는 행정 영역으로 설명한다. 사용자의 주체 이름에는 등록된 Realm이 들어가며, 요청을 받은 서비스는 이를 근거로 요청을 받아들일지 정할 수 있다. 다른 Realm으로 인증을 넘기려면 관리자가 Realm 간 키를 설정한다. 방향별로 서로 다른 키를 둘 수도 있다. 원격 Realm은 상대편의 티켓 발급 서비스를 주체로 등록하고, 원격 KDC는 공유 키로 상대 Realm이 발급한 티켓을 복호화한다.

그래서 사용자는 목적지마다 별도 계정을 만들 필요가 없다. 먼저 로컬 쪽에서 원격 Realm의 티켓 발급 서비스용 티켓을 얻고, 그것으로 대상 애플리케이션 티켓을 요청한다. 공유 키가 암호학적 다리라면, 다리를 놓고 유지할지는 관리자가 내리는 신뢰 결정이다.

중간 Realm은 모이고, 순서는 빠진다

경로에는 Realm이 여럿 들어갈 수 있다. RFC 1510이 흔한 구조로 든 것은 계층형 조직이다. 각 Realm은 부모와 키를 공유하고 자식 Realm마다 다른 키를 쓴다. 양 끝이 직접 키를 공유하지 않아도 계층을 이용해 경로를 만들 수 있다. 효율을 위해 중간 Realm을 건너뛰는 대체 경로도 허용한다. 계층이 없는 구성에서는 다른 데이터베이스를 조회해야 할 수 있다.

RFC 1510은 중간 Realm 이름을 순서 없는 집합으로 저장하고 흔한 계층형 이름을 압축한다. 따라서 통과 순서는 이 필드 밖에 있다. 시간순 재구성이 필요하면 별도의 운영 기록이 필요하다.

티켓 발급 서비스는 받은 티켓을 발급한 이전 Realm을 추가하고 자신의 Realm은 필드 밖에 둔다. RFC 1510의 의도는 서버가 자기 이름만 빼서 참여를 숨기는 일을 막는 것이다. 다른 Realm을 생략할 여지는 남으므로, 서비스를 받는 쪽은 나머지 기록을 자체 신뢰 정책으로 평가해야 한다.

2005년 7월 RFC 4120은 RFC 1510을 대체하면서 검사 책임을 더 분명히 했다. 인증을 최종 수락하거나 거부하는 주체는 애플리케이션 서버다. 서버는 참여한 KDC가 해당 사용자를 인증할 만큼 신뢰할 수 있는지 확인해야 한다. 목적지 Realm의 KDC가 자체 정책으로 transited를 검사한 뒤 서비스 티켓에 TRANSITED-POLICY-CHECKED를 표시할 수도 있다. KDC가 검사하지 않았다면 애플리케이션이 직접 확인하거나 표시가 없는 Realm 간 티켓을 거부해야 한다. RFC 4120은 신뢰할 수 없는 KDC가 목록을 조작했을 수 있다고도 경고한다.

권한은 세 곳에 나뉜다. 관리자는 Realm 간 키를 설정하고, KDC는 티켓을 발급해 검사 사실을 표시하며, 애플리케이션은 받아들일 경로를 정한다. 키 하나를 추가하면 접근 경로가 짧아질 수 있다. 동시에 연결된 서비스가 받아들일 수 있는 신원 범위도 넓어진다. 설정 파일에 키를 적는 순간 앞으로 어떤 서비스가 누구의 인증을 받아들일지가 정해지고, 그 경로가 네트워크 다이어그램에도 기록된다.

1993년 9월 RFC 1510은 프로토콜이 검토 중이며 당시 Internet 표준 심사를 위한 제출 단계가 아니라고 기록했다. RFC 4120은 2005년 Standards Track에 올라 구현 책임을 더 분명히 했다. 빠진 증거는 1990년대 어떤 애플리케이션 서버가 transited를 검사했는지 보여 주는 배포 기록이다. 그 기록이 있어야 실제 시스템에서 이 통제가 작동했는지 판단할 수 있고, RFC는 설계 의도를 보여 준다.

출처