Kerberos (프로토콜)

Kerberos (protocol)
이 기사는 프로토콜에 관한 것이다.그 외의 사용법에 대해서는, Kerberos 를 참조해 주세요.
케르베로스
개발자매사추세츠 공과대학
안정된 릴리스
버전 5, 릴리즈 1.20 / 2022년 5월 26일, 2개월 전(2022-05-26)[1]
기입처C
운영 체제크로스 플랫폼
크기8512k(소스 코드)
유형인증 프로토콜
웹 사이트web.mit.edu/kerberos/

Kerberos(/'k'rb's/)는 티켓에 따라 동작하는 컴퓨터 네트워크 인증 프로토콜로, 비보안 네트워크를 통해 통신하는 노드가 서로 식별 정보를 안전하게 증명할 수 있도록 합니다.설계자는 주로 클라이언트-서버 모델을 목표로 하고 있으며, 사용자와 서버 모두 서로의 ID를 확인하는 상호 인증을 제공합니다.Kerberos 프로토콜 메시지는 도청 및 재생 공격으로부터 보호됩니다.

Kerberos는 대칭키 암호화를 기반으로 구축되어 신뢰할 수 있는 서드파티가 필요합니다.[2]또한 인증의 특정 단계에서 옵션으로 공개키 암호화를 사용할 수도 있습니다.Kerberos는 기본적으로 UDP 포트 88을 사용합니다.

이 의전은 그리스 신화에 나오는 케르베로스라는 캐릭터, 하데스의 사나운 세 개의 머리를 가진 경비견에서 이름을 따왔다.

역사와 발전

MIT(Massachusetts Institute of Technology)는 프로젝트 [3][4]Athena가 제공하는 네트워크 서비스를 보호하기 위해 Kerberos를 개발했습니다.이 프로토콜은 이전의 Needham-Schroeder 대칭 키 프로토콜을 기반으로 합니다.프로토콜에는 여러 버전이 있습니다. 버전 1 ~ 3은 MIT에서 내부적으로만 발생했습니다.

Kerberos 버전 4는 주로 Steve Miller와 Clifford Neuman에 [5]의해 설계되었다.1980년대 후반에 출판된 버전 4도 프로젝트 Athena를 대상으로 했습니다.

Neuman과 John Kohl은 기존의 제한과 보안 문제를 극복하고자 1993년에 버전 5를 발표했습니다.버전 5는 RFC 1510으로 표시되었지만 2005년에 RFC 4120에 의해 폐지되었습니다.

미국 당국은 Kerberos가 데이터 암호화 규격(DES) 암호화 알고리즘(56비트 키 포함)을 사용했다는 이유로 군수품 목록에 '보조 군사 장비'로 분류하고 수출을 금지했다.스웨덴 왕립공과대학에서 개발된 Kerberos 4 실장(KTH-KRB 버전5에서 Heimdal로 변경)은 미국이 암호화 수출 규정을 변경하기 전에 미국 밖에서 시스템을 사용할 수 있도록 했습니다(약 2000년).스웨덴에서의 실장은 eBones라고 불리는 제한된 버전에 근거하고 있었습니다.eBones는 버전 Kerberos 4 패치레벨 9에 근거해 내보낸 MIT Bones 릴리스(암호화 기능과 그 양쪽의 콜의 스트라이핑)에 근거하고 있습니다.

2005년에 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회) Kerberos 작업 그룹은 사양을 업데이트했습니다.포함된 업데이트:

  • 암호화 및 체크섬 사양(RFC 3961)
  • Kerberos 5의 Advanced Encryption Standard(AES; 고도 암호화 규격) 암호화(RFC 3962)
  • Kerberos V5 사양의 새로운 에디션 「The Kerberos Network Authentication Service (V5)」(RFC 4120).이 버전은 RFC 1510을 폐지하고 프로토콜의 측면과 의도된 용도를 보다 상세하고 명확하게 설명합니다.
  • Generic Security Services Application Program Interface(GSS-API; 범용 보안 서비스 애플리케이션 프로그램인터페이스)의 새로운 사양 「Kerberos 버전5 Generic Security Service Application Program Interface(GSS-API; 범용 보안 서비스 애플리케이션프로그램 인터페이스)」메커니즘:버전 2 인치(RFC 4121)

MIT는 BSD에 사용되는 것과 유사한 저작권 권한 하에 Kerberos를 자유롭게 구현할 수 있도록 합니다.2007년 MIT는 지속적인 개발을 촉진하기 위해 Kerberos Consortium을 결성했습니다.설립 스폰서에는 Oracle, Apple Inc., Google, Microsoft, Centrify Corporation 및 TeamF1 Inc. 등의 벤더와 스웨덴 왕립공과대학, 스탠퍼드대학교, MIT 등의 학술기관 및 Cyber Safe 등의 벤더가 포함되어 있습니다.

Microsoft Windows

Windows 2000 이후 버전에서는 기본 [6]인증 방식으로 Kerberos가 사용됩니다.Kerberos 프로토콜 스위트에 대한 일부 Microsoft 추가 사항은 RFC 3244 "Microsoft Windows 2000 Kerberos 비밀번호 변경 및 비밀번호 설정 프로토콜"에 설명되어 있습니다.RFC 4757 에서는, Microsoft 의 RC4 암호의 사용이 문서화되어 있습니다.Microsoft는 Kerberos 프로토콜을 사용하고 확장하지만 MIT 소프트웨어는 사용하지 않습니다.

Kerberos는 권장되는 인증방식으로 사용됩니다.일반적으로 클라이언트를 Windows 도메인에 참여시키는 것은 해당 클라이언트에서 Windows 도메인의 서비스 및 해당 [6]도메인에 대한 트러스트 관계를 가진 모든 도메인에 대한 인증을 위한 기본 프로토콜로 Kerberos를 활성화하는 것을 의미합니다.

반면 클라이언트 또는 서버 중 하나 또는 둘 다 도메인에 가입하지 않은 경우(또는 동일한 신뢰 도메인 환경의 일부가 아닌 경우) Windows는 클라이언트와 [6]서버 간의 인증에 NTLM을 사용합니다.

인터넷 웹 응용 프로그램은 SSPI에서 제공되는 API를 사용하여 도메인 가입 클라이언트의 인증 방식으로서 Kerberos를 적용할 수 있습니다.

Microsoft Windows 및 Windows Server에는 다음이 포함됩니다.setspn: Active Directory 서비스 [7][8]계정의 SPN(Service Principal Name) 읽기, 변경 또는 삭제에 사용할 수 있는 명령줄 유틸리티입니다.

Unix 및 기타 운영 체제

FreeBSD, OpenBSD, Apple의 MacOS, Red Hat Enterprise Linux, Oracle의 Solaris, IBM의 AIX, HP-UX 등을 포함한 많은 Unix 유사 운영 체제에는 사용자 또는 서비스의 Kerberos 인증을 위한 소프트웨어가 포함되어 있습니다.z/OS, IBM i 및 OpenVMS와 같은 Unix가 아닌 다양한 운영 체제도 Kerberos를 지원합니다.임베디드 플랫폼에서 실행되는 클라이언트 에이전트 및 네트워크 서비스용 Kerberos V 인증 프로토콜의 임베디드 구현도 기업에서 이용할 수 있습니다.

프로토콜

묘사

클라이언트는 Authentication Server(AS; 인증 서버)에 대해 자신을 인증하고, Authentication Server(AS; 인증 서버)는 사용자 이름을 Key Distribution Center(KDC; 키 배포 센터)에 전송합니다.KDC는 Ticket-Granting Ticket(TGT; 티켓 인가 티켓)을 발행합니다.Ticket-Granting Service(TGS; 티켓 인가 서비스)의 개인 키를 사용하여 타임스탬프가 찍혀 암호화되고 암호화된 결과가 사용자의 워크스테이션에 반환됩니다.이 조작은, 통상은 유저 로그인시에 드물게 행해집니다.TGT는, 로그인중에 유저의 세션 매니저에 의해서 투과적으로 갱신되는 경우가 있습니다만, 어느 시점에서 기한이 만료됩니다.

클라이언트가 다른 노드(Kerberos 용어로는 「주요」)의 서비스와 통신할 필요가 있는 경우, 클라이언트는 TGT를 TGS로 송신합니다.TGS는 보통 KDC와 같은 호스트를 공유합니다.서비스는 Service Principal Name(SPN; 서비스 사용자명)으로 TGS에 등록되어 있어야 합니다.클라이언트는 SPN을 사용하여 이 서비스에 대한 액세스를 요구합니다.TGT가 유효하고 사용자가 요청된 서비스에 액세스할 수 있는지 확인한 후 TGS는 티켓 및 세션키를 클라이언트에 발행합니다.다음으로 클라이언트는 서비스 요청과 함께 티켓을 서비스 서버(SS)로 전송합니다.

Kerberos 협상

프로토콜은 아래에 자세히 설명되어 있습니다.

Kerberos를 사용하지 않는 사용자 클라이언트 기반 로그인

  1. 사용자가 클라이언트머신에 사용자 이름과 비밀번호를 입력합니다.pkinit(RFC 4556)등의 다른 credential 메카니즘에서는, 패스워드 대신에 공개 키를 사용할 수 있습니다.클라이언트는 패스워드를 대칭 암호 키로 변환합니다.이 경우 사용되는 암호 스위트에 따라 내장된 키스케줄링 또는 단방향 해시가 사용됩니다.
  2. 서버는 사용자 이름과 대칭 암호를 수신하여 데이터베이스의 데이터와 비교합니다.암호가 사용자용으로 저장된 암호와 일치할 경우 로그인은 성공했습니다.

클라이언트 인증

  1. 클라이언트는 사용자 ID의 클리어 텍스트메시지를 사용자를 대신하여 서비스를 요구하는 AS(Authentication Server)로 보냅니다(주의:비밀키도 패스워드도 AS에 송신되지 않습니다).
  2. AS는 클라이언트가 데이터베이스에 있는지 여부를 확인합니다.이 경우 AS는 데이터베이스에서 발견된 사용자의 패스워드(Windows Server의 Active Directory 등)를 해시하여 개인키를 생성하고 다음 2개의 메시지를 클라이언트에 반환합니다.
    • 메시지 A: 클라이언트/사용자의 개인 키를 사용하여 암호화된 클라이언트/TGS 세션 키.
    • 메시지 B: TGS의 개인 키를 사용하여 암호화된 Ticket-Granting-Ticket(TGT. 클라이언트 ID, 클라이언트네트워크 주소, 티켓 유효기간 및 클라이언트/TGS 세션키 포함).
  3. 클라이언트는 메시지A 및 B를 수신하면 사용자가 입력한 비밀번호에서 생성된 개인키를 사용하여 메시지A의 복호화를 시도합니다.사용자가 입력한 패스워드가 AS 데이터베이스 내의 패스워드와 일치하지 않으면 클라이언트의 개인키는 달라지기 때문에 메시지A를 복호화할 수 없습니다.유효한 패스워드와 비밀키를 사용하여 클라이언트는 메시지A를 복호화하여 클라이언트/TGS 세션키를 취득합니다.이 세션 키는 TGS와의 추가 통신에 사용됩니다(주의:메시지 B는 TGS의 개인 키를 사용하여 암호화되어 있기 때문에 클라이언트는 복호화할 수 없습니다).이 시점에서 클라이언트는 자신을 TGS에 인증하기에 충분한 정보를 얻을 수 있습니다.

클라이언트 서비스 인가

  1. 서비스를 요구할 때 클라이언트는 다음 메시지를 TGS로 전송합니다.
    • 메시지 C: 메시지 B(TGS 비밀키를 사용하여 암호화된TGT)와 요청된 서비스의 ID로 구성됩니다.
    • 메시지 D: 클라이언트/TGS 세션키를 사용하여 암호화되는 오센티케이터(클라이언트 ID와 타임스탬프로 구성됨).
  2. 메시지 C 및 D를 수신하면 TGS는 메시지C에서 메시지B를 가져옵니다.TGS 비밀키를 사용하여 메시지B를 복호화합니다.이것에 의해, 클라이언트/TGS 세션 키와 클라이언트 ID(둘 다 TGT 에 있습니다)가 취득됩니다.이 Client/TGS Session Key를 사용하여 TGS는 메시지D(Authenticator)를 복호화하여 메시지B와 D의 클라이언트 ID를 비교합니다.일치하면 서버는 다음 2개의 메시지를 클라이언트에 발송합니다.
    • 메시지 E: 서비스 개인 키를 사용하여 암호화된 클라이언트 간 티켓(클라이언트 ID, 클라이언트 네트워크 주소, 유효 기간 및 클라이언트/서버 세션 키 포함).
    • 메시지 F: 클라이언트/TGS 세션 키로 암호화된 클라이언트/서버 세션 키.

클라이언트 서비스 요청

  1. TGS에서 메시지E 및 F를 수신하면 클라이언트는 Service Server(SS; 서비스 서버)에 대해 자신을 인증하기에 충분한 정보를 얻을 수 있습니다.클라이언트는 SS에 접속하여 다음 2개의 메시지를 보냅니다.
    • 메시지 E: 이전 단계(클라이언트-서버 티켓, 서비스 개인 키를 사용하여 암호화).
    • 메시지 G: 클라이언트 ID, 타임스탬프 및 클라이언트/서버 세션 키를 사용하여 암호화되는 새로운 인증 프로그램.
  2. SS는 자체 개인 키를 사용하여 티켓(메시지E)을 복호화하여 클라이언트/서버 세션키를 가져옵니다.SS는 sessions 키를 사용하여 Authenticator를 복호화하고 메시지E 및 G에서 클라이언트 ID를 비교합니다.서버와 일치하는 경우 클라이언트에 다음 메시지가 발송되어 클라이언트에 대한 실제 ID와 서비스 의사가 확인됩니다.
    • 메시지 H: 클라이언트/서버 세션 키를 사용하여 암호화된 클라이언트의 오센티케이터(버전 4에서는 1이 추가되지만 버전[9][10] 5에서는 필요하지 않음)에 있는 타임스탬프입니다.
  3. 클라이언트는 클라이언트/서버 세션키를 사용하여 확인(메시지 H)을 복호화하고 타임스탬프가 올바른지 여부를 확인합니다.이 경우 클라이언트는 서버를 신뢰할 수 있으며 서버에 대한 서비스 요청을 시작할 수 있습니다.
  4. 서버는 클라이언트에 요청된 서비스를 제공합니다.

결점 및 제한 사항

  • Kerberos에는 엄격한 시간 요건이 있습니다.즉, 관련된 호스트의 클럭은 설정된 제한 내에서 동기화되어야 합니다.티켓에는 이용 가능한 시간이 있으며 호스트 클락이 Kerberos 서버 클럭과 동기화되지 않으면 인증이 실패합니다.MIT 단위의 디폴트 설정에서는, 클럭 타임이 5 분 이내로 설정되어 있을 필요가 있습니다.실제로 호스트 클럭을 동기화하기 위해 Network Time Protocol 데몬을 사용합니다.양쪽 클럭의 오프셋이 설정된 최대값보다 클 경우 일부 서버(Microsoft 실장 중 하나)는 암호화된 서버 시간을 포함한 KRB_AP_ERR_SKEW 결과를 반환할 수 있습니다.이 경우 클라이언트는 제공된 서버 시간을 사용하여 오프셋을 찾아 시간을 계산하여 재시도할 수 있습니다.이 동작은 RFC 4430에 기재되어 있습니다.
  • 관리 프로토콜은 표준화되지 않았으며 서버 구현에 따라 다릅니다.패스워드의 변경에 대해서는, RFC 3244 에 기재되어 있습니다.
  • 대칭 암호 방식을 채택한 경우(Kerberos는 대칭 또는 비대칭(공개 키) 암호 방식을 사용할 수 있습니다.모든 인증은 중앙집중형 키 배포 센터(KDC)에 의해 제어되기 때문에 인증 인프라스트럭처를 손상시키면 공격자가 모든 사용자를 가장할 수 있습니다.
  • 다른 호스트명을 필요로 하는 각 네트워크 서비스에는, 독자적인 Kerberos 키 세트가 필요합니다.이로 인해 가상 호스팅과 클러스터가 복잡해집니다.
  • Kerberos를 사용하려면 사용자 계정과 서비스가 Kerberos 토큰 서버와 신뢰할 수 있는 관계를 가져야 합니다.
  • 필요한 클라이언트 신뢰로 인해 단계적 환경(테스트 환경, 사전 운영 환경 및 운영 환경용 개별 도메인 등)을 만드는 것이 어려워집니다.환경 도메인을 엄격하게 분리할 수 없도록 도메인 트러스트 관계를 만들거나 환경별로 추가 사용자 클라이언트를 제공해야 합니다.

취약성

Data Encryption Standard(DES; 데이터 암호화 표준) 암호는 Kerberos와 조합하여 사용할 수 있지만 [11]취약하기 때문에 인터넷 표준이 아닙니다.Kerberos를 구현하는 많은 레거시 제품에는 DES 대신 AES와 같은 새로운 암호를 사용하도록 업데이트되지 않았기 때문에 보안 취약성이 있습니다.

2014년 11월에 Microsoft는 Kerberos Key Distribution Center(KDC)[12]의 Windows 구현에서 부정 이용 가능한 취약성을 수정하기 위한 패치(MS14-068)를 릴리스했습니다.이 취약성을 통해 사용자는 도메인 수준까지 권한을 "강화"(및 남용)할 수 있다고 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Kerberos 5 Release 1.20".
  2. ^ RFC 4556, 추상.
  3. ^ Steiner, Jennifer G.; Geer, Daniel E. (21 July 1988). Network Services in the Athena Environment. Proceedings of the Winter 1988 Usenix Conference. CiteSeerX 10.1.1.31.8727.
  4. ^ Elizabeth D. Zwicky; Simon Cooper; D. Brent (26 Jun 2000). Building Internet Firewalls: Internet and Web Security. O'Reilly. ISBN 9781565928718.
  5. ^ Steiner, Jennifer G.; Neuman, Clifford; Schiller, Jeffrey I. (February 1988). Kerberos: An authentication service for open network systems. Proceedings of the Winter 1988 USENIX Conference. CiteSeerX 10.1.1.112.9002. S2CID 222257682.
  6. ^ a b c "What Is Kerberos Authentication?". Microsoft TechNet. Archived from the original on 2016-12-20.
  7. ^ Setspn - Windows CMD - SS64.com
  8. ^ Setspn Microsoft 문서
  9. ^ C., Neuman; J., Kohl. "The Kerberos Network Authentication Service (V5)". Archived from the original on 2016-08-21.
  10. ^ Clifford, Neuman; Sam, Hartman; Tom, Yu; Kenneth, Raeburn. "The Kerberos Network Authentication Service (V5)". Archived from the original on 2016-08-21.
  11. ^ Tom, Yu; Love, Astrand. "Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos". Archived from the original on 2015-10-27.
  12. ^ Seltzer, Larry. "Details emerge on Windows Kerberos vulnerability - ZDNet". ZDNet. Archived from the original on 2014-11-21.
일반
RFC
  • RFC 1510 Kerberos 네트워크 인증 서비스(V5) [구식]
  • RFC 1964 Kerberos 버전5 GSS-API 메커니즘
  • RFC 3961 Kerberos 5 암호화 및 체크섬 사양
  • RFC 3962 Kerberos 5의 Advanced Encryption Standard(AES) 암호화
  • RFC 4120 Kerberos 네트워크 인증 서비스(V5) [현재]
  • RFC 4121 Kerberos 버전5 GSS-API 메커니즘:버전 2
  • RFC 4537 Kerberos 암호 시스템네고시에이션 확장
  • RFC 4556 Kerberos(PKINIT)에서의 초기 인증을 위한 공개 키 암호화
  • RFC 4557 Kerberos(PKINIT)에서의 초기 인증을 위한 공개 키 암호화에 대한 OCSP(Online Certificate Status Protocol) 지원
  • RFC 4757 Microsoft Windows에서 사용되는 RC4-HMAC Kerberos 암호화 유형 [구식]
  • RFC 5021 확장 Kerberos 버전5 Key Distribution Center(KDC; 키 배포 센터)의 TCP 경유 교환
  • RFC 5349 Kerberos(PKINIT)에서의 초기인증을 위한 공개키 암호화(ECC) 지원
  • RFC 5868 Kerberos 크로스 레름 동작에 관한 문제문
  • RFC 5896 범용 보안 서비스 애플리케이션 프로그램 인터페이스(GSS-API):정책에 의해 승인된 경우 위임
  • RFC 6111 기타 Kerberos 명명 제약사항
  • RFC 6112 Kerberos 익명 지원
  • RFC 6113 Kerberos 사전 인증을 위한 범용 프레임워크
  • RFC 6251 TLS(Transport Layer Security) 프로토콜을 통한 Kerberos 버전5 사용
  • RFC 6448 Kerberos 5 KRB-CRED 메시지의 암호화되지 않은 형식
  • RFC 6542 Kerberos 버전5 GSS-API 채널바인딩 해시 민첩성
  • RFC 6560 원타임패스워드(OTP) 사전인증
  • RFC 6649 Kerberos에서의 DES, RC4-HMAC-EXP 및 기타 취약한 암호화 알고리즘 폐지
  • RFC 6784 DHCPv6의 Kerberos 옵션
  • RFC 6803 Kerberos 5의 동백 암호화
  • RFC 6806 Kerberos 주요 이름 정규화와 크로스 레름 참조
  • RFC 6880 Kerberos 버전5의 정보 모델

추가 정보

외부 링크

Wikimedia Commons에는 Kerberos 관련 미디어가 있습니다.