맨위로가기

커버로스

"오늘의AI위키"는 AI 기술로 일관성 있고 체계적인 최신 지식을 제공하는 혁신 플랫폼입니다.
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.

1. 개요

커버로스는 매사추세츠 공과대학교(MIT)에서 1980년대 개발한 네트워크 인증 프로토콜이다. 초기 버전은 MIT 내부에서 사용되었으며, 1989년 외부 공개된 버전 4는 미국의 암호화 기술 수출 제한으로 인해 수출에 제약이 있었다. 이후 버전 5가 발표되었고, 인터넷 엔지니어링 태스크 포스(IETF)에서 사양을 업데이트했다. 커버로스는 키 분배 센터(KDC)를 중심으로 작동하며, 클라이언트가 인증 서버(AS)에 인증을 요청하면 티켓 승인 티켓(TGT)을 발급받아 다른 서비스에 접근한다. 윈도우 운영체제에서 기본 인증 방법으로 사용되며, 유닉스 계열 및 다양한 운영체제에서 지원된다. 단점으로는 시계 동기화의 엄격한 요구 사항, 중앙 집중식 KDC로 인한 보안 취약성 등이 있다.

더 읽어볼만한 페이지

  • 인증 프로토콜 - 확장 가능 인증 프로토콜
    확장 가능 인증 프로토콜(EAP)은 다양한 인증 방식을 지원하며, IEEE 802.1X 등 여러 프로토콜에서 캡슐화되어 LAN, 특히 무선 LAN 환경에서 사용자 인증에 활용된다.
  • 인증 프로토콜 - 챌린지-핸드셰이크 인증 규약
    챌린지-핸드셰이크 인증 규약(CHAP)은 점대점 프로토콜 환경에서 서버가 클라이언트를 인증하기 위해 설계된 프로토콜로, 3방향 핸드셰이크를 통해 주기적으로 인증하며, 서버가 챌린지 메시지를 보내고 클라이언트가 해시 함수로 응답하는 방식으로 작동하지만, 암호 저장 및 사전 공격에 취약한 단점이 있다.
  • 케르베로스 - 오르토스
    그리스 신화에 등장하는 머리 둘 달린 개 오르토스는 거인 게리온의 소 떼를 지키다 헤라클레스에게 죽임을 당했으며, 케르베로스와 유사하고 스핑크스와 네메아의 사자의 아버지로도 알려져 있다.
  • 케르베로스 - 케르베로스 (위성)
    케르베로스는 2011년 허블 우주 망원경으로 발견된 명왕성의 위성으로, 닉스와 히드라 궤도 사이를 약 32일 주기로 공전하며, 이중 엽 모양의 불규칙한 형태에 물 얼음이 존재하고, 2015년 뉴 호라이즌스 우주선에 의해 촬영되었다.
  • 컴퓨터 접근 제어 프로토콜 - RADIUS
    RADIUS는 네트워크 접근 관리에 사용되는 AAA 프로토콜로, 클라이언트-서버 모델을 기반으로 사용자 인증 및 권한 부여를 수행하며 다양한 환경에서 활용된다.
  • 컴퓨터 접근 제어 프로토콜 - OAuth
    OAuth는 웹/앱 환경에서 사용자 인증 및 API 접근 권한 위임을 위한 개방형 표준 프로토콜로, 버전 1.0과 2.0을 거쳐 2.1 초안이 진행 중이며, 널리 사용되지만 복잡성과 보안 문제에 대한 논쟁도 있다.
커버로스 - [IT 관련 정보]에 관한 문서
일반 정보
이름Kerberos
종류인증 프로토콜
개발매사추세츠 공과대학교
최신 버전버전 5, 릴리스 1.21
최신 릴리스 날짜2023년 6월 5일
프로그래밍 언어C
운영 체제크로스 플랫폼
웹사이트Kerberos 공식 웹사이트
추가 정보
발음 (IPA)/ˈkɜːrbərɒs/

2. 역사

커버로스는 매사추세츠 공과대학교(MIT)의 아테나 프로젝트에서 네트워크 서비스 보안을 위해 개발되었다. 초기 설계는 스티브 밀러와 클리포드 뉴먼이 니덤-슈뢰더 대칭 키 프로토콜을 기반으로 진행했다.[5][6]

커버로스 버전 4는 데이터 암호화 표준(DES)을 사용했기 때문에, 미국 정부의 암호화 소프트웨어 수출 규제로 인해 미국 외에서는 사용에 제한이 있었다.[22] 이러한 문제를 해결하기 위해, MIT는 암호화 코드를 제거한 "Bones" 버전을 만들었고, 호주의 에릭 영이 DES를 재구현한 "eBones" 버전을 개발하여 전 세계적으로 사용이 가능하게 되었다.[23]

1993년 뉴먼과 존 콜은 버전 5를 발표했다. 버전 5는 [http://www.rfc-editor.org/info/rfc1510 RFC 1510]으로 나타났으며, 2005년에 [http://www.rfc-editor.org/info/rfc4120 RFC 4120]에 의해 대체되었다.

2005년, 인터넷 엔지니어링 태스크 포스(IETF) 커버로스 워킹 그룹은 사양을 업데이트했다.

MIT는 커버로스 구현을 BSD 라이선스와 유사한 조건으로 자유롭게 사용할 수 있도록 했다. 2007년에는 지속적인 개발을 위해 커버로스 컨소시엄이 결성되었다.

2. 1. 개발 과정

매사추세츠 공과대학교(MIT)는 1988년 아테나 프로젝트에서 제공하는 네트워크 서비스를 보호하기 위해 커버로스를 개발했다.[4] 초판은 스티브 밀러와 클리포드 뉴먼이 초기 니덤-슈뢰더 대칭 키 프로토콜을 기반으로 주로 설계했다.[5][6] 커버로스 버전 1부터 3까지는 실험적인 버전이었으며 MIT 외부에는 공개되지 않았다.[21]

1980년대 매사추세츠 공과대학교(MIT)에서 연구 프로젝트로 시작되었다.[18] MIT의 아테나 프로젝트는 시작 초기부터 클라이언트-서버 모델을 상정하여 설계되었으며, 그 네트워크 인증을 위해 Kerberos 프로토콜이 개발되었다.[19][20] 이 인증 시스템은 경로 상에서의 도청을 방지하기 위해, 인증 서버와 그 외 컴퓨터 간의 인증 교환을 암호화하고 있다.[19]

커버로스 버전 4는 최초의 공개 버전으로 1989년 1월 24일에 출시되었다.[21] 커버로스 4는 미국에서 개발되었고, 데이터 암호화 표준(DES) 암호화 알고리즘을 사용했기 때문에, 미국 암호화 기술 수출 제한으로 인해 다른 국가로 수출할 수 없었다.[22] MIT는 암호화 코드를 모두 제거한 커버로스 4의 수출 가능 버전을 만들었으며, 이를 "Bones"라고 불렀다.[23] 호주 본드 대학교의 에릭 영은 DES를 Bones에 재구현하여 "eBones"라는 버전을 만들었고, 이 버전은 어떤 국가에서든 자유롭게 사용할 수 있게 되었다.[23] 스웨덴의 왕립 공과대학교는 KTH-KRB라는 또 다른 재구현 버전을 출시했다.

뉴먼과 존 콜은 기존의 제한 사항과 보안 문제를 극복하기 위해 1993년에 버전 5를 발표했다. 버전 5는 으로 나타났으며, 2005년에 으로 대체되었다.

2005년, 인터넷 엔지니어링 태스크 포스(IETF) 커버로스 워킹 그룹은 사양을 업데이트했다. 업데이트 내용은 다음과 같다.

  • 암호화 및 체크섬 사양().
  • 고급 암호화 표준(AES) 커버로스 5 암호화().
  • 커버로스 V5 사양의 새로운 판 "The Kerberos Network Authentication Service (V5)"(). 이 버전은 RFC 1510을 대체하며, 프로토콜의 측면과 의도된 사용을 보다 자세하고 명확하게 설명한다.
  • 일반 보안 서비스 응용 프로그램 인터페이스(GSS-API) 사양의 새로운 판 "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2"().


MIT는 커버로스의 구현을 BSD 라이선스와 유사한 저작권 허가 조건으로 자유롭게 사용할 수 있도록 한다. 2007년, MIT는 지속적인 개발을 촉진하기 위해 커버로스 컨소시엄을 결성했다. 창립 후원사로는 오라클(Oracle), 애플(Apple Inc.), 구글(Google), 마이크로소프트(Microsoft), 센트리파이 코퍼레이션(Centrify Corporation) 및 TeamF1 Inc.와 같은 벤더와 스웨덴의 왕립 공과대학교, 스탠포드 대학교, MIT와 같은 학술 기관, 그리고 상업적으로 지원되는 버전을 제공하는 사이버세이프(CyberSafe)와 같은 벤더가 포함되어 있다.

3. 프로토콜

커버로스 프로토콜은 키 분배 센터(KDC)를 중심으로 구성되며, KDC는 인증 서버(AS)와 티켓 승인 서비스(TGS)로 구성된다.[7][8]

클라이언트는 KDC의 AS에 자신을 인증하고, AS는 티켓 승인 티켓(TGT)을 발급한다. TGT는 타임스탬프가 찍혀 있으며, TGS의 비밀 키를 사용하여 암호화된 후 클라이언트에게 반환된다. 사용자는 로그인할 때 이 과정을 거치며, TGT는 만료되지만 세션 관리자에 의해 자동으로 갱신된다.

클라이언트가 다른 서비스와 통신해야 할 경우, TGT를 TGS로 보낸다. 서비스는 서비스 주체 이름(SPN)으로 TGS에 등록되어 있어야 하며, 클라이언트는 SPN을 사용하여 서비스 접근을 요청한다. TGS는 TGT의 유효성과 사용자 권한을 확인한 후, 서비스 티켓(ST)과 세션 키를 클라이언트에게 발급한다. 클라이언트는 이 티켓을 서비스 요청과 함께 서비스 서버(SS)로 보낸다.

커버로스 프로토콜은 사용자의 ID/패스워드 사용을 최소화하고, TGT를 서비스 주체에게 직접 보내지 않아 보안을 강화한다. 사용자는 처음에 AS로부터 인증받을 때만 ID/패스워드를 사용하고, 이후에는 TGT를 이용해 TGS로부터 인증을 받는다. 또한, TGT를 서비스 주체에게 직접 보내는 대신 TGS를 통해 해당 서비스에 대한 접근에만 사용할 수 있는 ST를 발급받아 사용한다.

3. 1. 기본 구조

커버로스는 사용자, 머신, 서비스를 인증하고 보안 통신을 가능하게 하는 네트워크 프로토콜이다. 다음은 커버로스의 기본 구조와 관련된 용어들이다.

  • '''렐름(Realm)''': 커버로스 서버를 운영하는 조직의 자체적인 영역을 의미한다.
  • '''프린시펄(Principal)''': 렐름에 속하는 머신이나 서비스를 지칭한다.
  • '''키 분배 센터(KDC, Key Distribution Center)''': 키 배포 센터라고 불리며, 렐름 내에서 권한을 가진 주체이다. KDC는 다음과 같은 구성 요소를 가진다.
  • '''인증 서버(AS, Authentication Server)''': 클라이언트의 최초 인증을 담당한다.
  • '''티켓 승인 서비스(TGS, Ticket Granting Server)''': 클라이언트가 특정 서비스에 접근할 수 있는 티켓을 발급한다.
[7][8]

3. 2. 작동 방식

Kerberos 협상


커버로스는 클라이언트가 키 분배 센터(KDC)의 인증 서버(AS)를 통해 자신을 인증하는 방식으로 작동한다. KDC는 티켓 승인 티켓(TGT)을 발급하며, 이 티켓은 타임스탬프가 찍혀 있고, 티켓 승인 서비스(TGS)의 비밀 키로 암호화되어 클라이언트의 워크스테이션으로 반환된다. 사용자는 로그인할 때 이 과정을 거치며, TGT는 만료되지만 세션 관리자에 의해 자동으로 갱신된다.

클라이언트가 다른 서비스와 통신해야 할 경우, TGT를 TGS로 보낸다. 서비스는 서비스 주체 이름(SPN)으로 TGS에 등록되어 있어야 하며, 클라이언트는 SPN을 사용하여 서비스 접근을 요청한다. TGS는 TGT의 유효성과 사용자 권한을 확인한 후, 서비스 티켓(ST)과 세션 키를 클라이언트에게 발급한다. 클라이언트는 이 티켓을 서비스 요청과 함께 서비스 서버(SS)로 보낸다.

프로토콜의 자세한 작동 방식은 다음과 같다.

1. 사용자는 클라이언트 머신에 사용자 이름과 비밀번호를 입력한다. 비밀번호 대신 공개 키를 사용할 수도 있다(pkinit, RFC 4556).

2. 서버는 사용자 이름과 비밀번호를 데이터베이스와 비교하여 일치하면 로그인을 승인한다.

3. 클라이언트는 사용자 ID를 평문으로 AS에 보내 서비스를 요청한다. (비밀 키나 암호는 AS로 전송되지 않는다.)

4. AS는 클라이언트가 데이터베이스에 있는지 확인하고, 사용자의 암호를 해싱하여 비밀 키를 생성한 후, 다음 두 메시지를 클라이언트에 보낸다.

  • 메시지 A: 클라이언트/TGS 세션 키 (클라이언트/사용자의 비밀 키로 암호화)
  • 메시지 B: 티켓 승인 티켓(TGT) (클라이언트 ID, 클라이언트 네트워크 주소, 티켓 유효 기간, 클라이언트/TGS 세션 키 포함, TGS의 비밀 키로 암호화)

5. 클라이언트는 메시지 A를 해독하여 클라이언트/TGS 세션 키를 얻는다. (메시지 B는 해독할 수 없다.)

6. 서비스를 요청할 때, 클라이언트는 TGS에 다음 메시지를 보낸다.

  • 메시지 C: 메시지 B (TGT)와 요청된 서비스의 ID
  • 메시지 D: 인증자 (클라이언트 ID와 타임스탬프, 클라이언트/TGS 세션 키로 암호화)

7. TGS는 메시지 B를 해독하여 클라이언트/TGS 세션 키와 클라이언트 ID를 얻고, 메시지 D를 해독하여 클라이언트 ID를 비교한다. 일치하면 다음 두 메시지를 클라이언트에 보낸다.

  • 메시지 E: 클라이언트-서버 티켓 (클라이언트 ID, 클라이언트 네트워크 주소, 유효 기간, 클라이언트/서버 세션 키 포함, 서비스의 비밀 키로 암호화)
  • 메시지 F: 클라이언트/서버 세션 키 (클라이언트/TGS 세션 키로 암호화)

8. 클라이언트는 SS에 다음 두 메시지를 보낸다.

  • 메시지 E: 클라이언트-서버 티켓
  • 메시지 G: 새로운 인증자 (클라이언트 ID, 타임스탬프, 클라이언트/서버 세션 키로 암호화)

9. SS는 티켓(메시지 E)을 해독하여 클라이언트/서버 세션 키를 얻고, 인증자를 해독하여 클라이언트 ID를 비교한다. 일치하면 다음 메시지를 클라이언트에 보낸다.

  • 메시지 H: 클라이언트의 인증자에서 발견된 타임스탬프(버전 4에서는 1을 더함, 버전 5에서는 불필요[7][8]) (클라이언트/서버 세션 키로 암호화)

10. 클라이언트는 메시지 H를 해독하고 타임스탬프를 확인하여 서버를 신뢰하고 서비스 요청을 시작한다.

11. 서버는 클라이언트에게 요청된 서비스를 제공한다.

사용자가 영역에 로그인하면 클라이언트 단말에서 ID/패스워드로 인증을 받고, 이 패스워드로 비밀 키 K를 생성한다. 클라이언트는 사용자 ID를 평문으로 AS에 보내고, AS는 사용자 ID로 데이터베이스를 조회하여 비밀 키 K를 얻는다.

AS는 TGT와 클라이언트/TGS 세션 키를 K로 대칭 키 암호화하여 클라이언트 단말과 TGS로 보낸다. TGT는 TGS로부터 "티켓"을 받기 위한 기본 티켓이며, 클라이언트/TGS 세션 키는 TGS로부터 티켓을 받을 때 사용하는 세션 키이다. 대칭 키 암호로는 버전 4에서 56비트 DES 암호를 사용한다.

사용자가 주체 A의 서비스를 이용하고 싶을 때, 클라이언트 단말은 TGT와 서비스 요청을 TGS로 보내며, 이 통신은 클라이언트/TGS 세션 키로 암호화된다. TGS는 TGT의 정당성을 확인하고, A의 서비스 이용 허가증인 티켓과 A와의 통신에 사용할 세션 키를 클라이언트 단말에 보낸다.

클라이언트 단말은 티켓 유효 기간 내에 티켓을 (세션 키로 암호화하여) 주체 A에게 보내면 A가 제공하는 서비스를 이용할 수 있다.

3. 3. 특징

커버로스는 사용자의 ID/패스워드 사용을 최소화하고, 티켓 승인 티켓(TGT)을 직접 서비스 주체에게 보내지 않는 방식으로 보안을 강화한다.
ID/패스워드 사용 최소화:사용자는 처음에 키 분배 센터의 인증 서버(AS)로부터 인증을 받을 때만 ID/패스워드를 사용한다. 이후에는 TGT를 사용하여 티켓 승인 서비스(TGS)로부터 인증을 받는다. 이를 통해 ID/패스워드 유출을 방지한다.[7][8]
TGT를 직접 서비스 주체(프린시펄)에게 보내지 않음:TGT를 직접 서비스 주체에게 보내면 해당 주체가 사용자로 가장할 수 있는 위험이 있다. 이를 방지하기 위해 TGS를 통해 해당 서비스에 대한 접근에만 사용할 수 있는 서비스 티켓(ST)을 발급받아 사용한다. 클라이언트는 TGS에 TGT를 보내 특정 서비스에 대한 접근 권한을 요청하고, TGS는 해당 서비스에만 유효한 ST를 발급한다. 이 ST는 서비스 서버(SS)에 제출되어 서비스 이용 권한을 얻는 데 사용된다.[7][8]

4. 운영체제 지원

마이크로소프트 윈도우 2000 및 이후 버전은 기본 인증 방법으로 커버로스를 사용한다.[9] 커버로스 프로토콜 제품군에 대한 마이크로소프트의 일부 추가 사항은 RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"에 문서화되어 있으며, RFC 4757은 RC4 암호에 대한 마이크로소프트의 사용을 문서화하고 있다.

FreeBSD, 애플의 macOS, Red Hat Enterprise Linux, 오라클의 Solaris, IBM의 AIX, HP-UX 등 다수의 유닉스 계열 운영체제가 사용자나 서비스의 커버로스 인증을 위한 소프트웨어를 포함하고 있다. z/OS, IBM i, OpenVMS와 같은 비유닉스 계열 운영체제 역시 커버로스를 지원한다.

4. 1. 마이크로소프트 윈도우

윈도우 2000 및 이후 버전은 기본 인증 방법으로 커버로스를 사용한다.[9] 커버로스 프로토콜 제품군에 대한 마이크로소프트의 일부 추가 사항은 RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols"에 문서화되어 있으며, RFC 4757은 RC4 암호에 대한 마이크로소프트의 사용을 문서화하고 있다.

커버로스는 선호되는 인증 방법으로 사용된다. 일반적으로 클라이언트를 윈도우 도메인에 가입한다는 것은 해당 클라이언트에서 윈도우 도메인 및 해당 도메인과 트러스트 관계가 있는 모든 도메인의 서비스에 대한 인증에 커버로스를 기본 프로토콜로 사용하도록 설정하는 것을 의미한다.[9]

반면, 클라이언트 또는 서버, 혹은 둘 다 도메인에 가입하지 않은 경우 (또는 동일한 트러스트된 도메인 환경의 일부가 아닌 경우) 윈도우는 대신 클라이언트와 서버 간의 인증에 NTLM을 사용한다.[9]

마이크로소프트 윈도우 및 윈도우 서버에는 명령줄 유틸리티인 `setspn`이 포함되어 있으며, 이 유틸리티는 액티브 디렉토리 서비스 계정에 대한 서비스 주체 이름(SPN)을 읽고, 수정하거나, 삭제하는 데 사용할 수 있다.[10][11]

4. 2. 유닉스 및 기타 운영체제

FreeBSD, 애플의 macOS, Red Hat Enterprise Linux, 오라클의 Solaris, IBM의 AIX, HP-UX 등 다수의 유닉스 계열 운영체제가 사용자나 서비스의 커버로스 인증을 위한 소프트웨어를 포함하고 있다. z/OS, IBM i, OpenVMS와 같은 비유닉스 계열 운영체제 역시 커버로스를 지원한다.

5. 단점 및 한계

커버로스는 다음과 같은 단점 및 한계를 갖는다.


  • 엄격한 시간 요구 사항: 관련된 호스트의 시계가 동기화되어야 한다. 티켓에는 시간 유효 기간이 있으며, 호스트 시계가 커버로스 서버 시계와 동기화되지 않으면 인증이 실패한다. 기본 구성(http://web.mit.edu/Kerberos/krb5-1.5/krb5-1.5.4/doc/krb5-admin/Clock-Skew.html MIT에 따르면)은 시계 시간이 5분 이상 차이가 나지 않아야 한다고 요구한다. 실제로는 네트워크 시간 프로토콜 데몬을 사용하여 호스트 시계를 동기화하는 것이 일반적이다.[1] 일부 서버는 두 시계의 오프셋이 큰 경우 암호화된 서버 시간을 포함하는 KRB_AP_ERR_SKEW 결과를 반환할 수 있다. 이 경우 클라이언트는 제공된 서버 시간을 사용하여 시간을 계산하여 오프셋을 찾아 다시 시도할 수 있다.[1]
  • 관리 프로토콜 비표준화: 관리 프로토콜은 표준화되어 있지 않으며 서버 구현에 따라 다르다. 비밀번호 변경은 [https://www.rfc-editor.org/rfc/rfc3244.html RFC 3244]에 설명되어 있다.[2]
  • 중앙 집중식 키 분배 센터(KDC)의 보안 취약점: 대칭 암호화 채택의 경우(커버로스는 대칭 또는 비대칭(공개 키) 암호화를 사용하여 작동 가능), 모든 인증이 중앙 집중식 키 분배 센터 (KDC)에서 제어되므로 이 인증 인프라가 손상되면 공격자가 모든 사용자를 가장할 수 있다.[3]
  • 가상 호스팅 및 클러스터 구성의 복잡성: 다른 호스트 이름이 필요한 각 네트워크 서비스는 자체 커버로스 키 집합이 필요하다. 이는 가상 호스팅 및 클러스터를 복잡하게 만든다.[4]
  • 클라이언트 신뢰 문제: 커버로스는 사용자 계정 및 서비스가 커버로스 토큰 서버와 신뢰 관계를 가져야 한다.[5] 필요한 클라이언트 신뢰는 스테이지 환경(예: 테스트 환경, 사전 프로덕션 환경 및 프로덕션 환경에 대한 별도의 도메인)을 만드는 것을 어렵게 만든다.[6] 환경 도메인의 엄격한 분리를 방지하는 도메인 신뢰 관계를 생성해야 하거나 각 환경에 대해 추가 사용자 클라이언트를 제공해야 한다.[6]

6. 보안

데이터 암호화 표준(DES) 암호는 커버로스와 함께 사용할 수 있지만, 안전하지 않아 더 이상 인터넷 표준으로 사용되지 않는다.[12] 레거시 버전의 커버로스를 구현한 제품은 고급 암호화 표준(AES)과 같은 최신 암호화 방식을 지원하지 않아 보안 취약점이 존재한다.

7. 관련 RFC

커버로스와 관련된 RFC는 다음과 같다.

RFC 번호내용
http://www.rfc-editor.org/info/rfc1510 RFC 1510커버로스 버전 5. 1993년에 발표되었으나, 2005년에 http://www.rfc-editor.org/info/rfc4120 RFC 4120에 의해 대체됨.[5][6]
http://www.rfc-editor.org/info/rfc1964 RFC 1964
http://www.rfc-editor.org/info/rfc3961 RFC 3961암호화 및 체크섬 사양.
http://www.rfc-editor.org/info/rfc3962 RFC 3962고급 암호화 표준(AES) 커버로스 5 암호화.
http://www.rfc-editor.org/info/rfc4120 RFC 4120커버로스 V5 사양. RFC 1510을 대체하며, 프로토콜 및 사용 목적을 보다 자세하고 명확하게 설명.
http://www.rfc-editor.org/info/rfc4121 RFC 4121일반 보안 서비스 응용 프로그램 인터페이스(GSS-API) 사양. "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2".
http://www.rfc-editor.org/info/rfc4537 RFC 4537
http://www.rfc-editor.org/info/rfc4556 RFC 4556
http://www.rfc-editor.org/info/rfc4557 RFC 4557
http://www.rfc-editor.org/info/rfc4757 RFC 4757
http://www.rfc-editor.org/info/rfc5021 RFC 5021
http://www.rfc-editor.org/info/rfc5349 RFC 5349
http://www.rfc-editor.org/info/rfc5868 RFC 5868
http://www.rfc-editor.org/info/rfc5896 RFC 5896
http://www.rfc-editor.org/info/rfc6111 RFC 6111
http://www.rfc-editor.org/info/rfc6112 RFC 6112
http://www.rfc-editor.org/info/rfc6113 RFC 6113
http://www.rfc-editor.org/info/rfc6251 RFC 6251
http://www.rfc-editor.org/info/rfc6448 RFC 6448
http://www.rfc-editor.org/info/rfc6542 RFC 6542
http://www.rfc-editor.org/info/rfc6560 RFC 6560
http://www.rfc-editor.org/info/rfc6649 RFC 6649
http://www.rfc-editor.org/info/rfc6784 RFC 6784
http://www.rfc-editor.org/info/rfc6803 RFC 6803
http://www.rfc-editor.org/info/rfc6806 RFC 6806
http://www.rfc-editor.org/info/rfc6880 RFC 6880


참조

[1] 웹사이트 Kerberos 5 Release 1.21 https://web.mit.edu/[...]
[2] 간행물 RFC 4556, abstract
[3] 웹사이트 Kerberos authentication https://www.ionos.co[...] 2022-08-25
[4] 학술 Network Services in the Athena Environment 1988-07-21
[5] 학술 "Kerberos'': An authentication service for open network systems 1988-02
[6] 서적 Building Internet Firewalls: Internet and Web Security https://archive.org/[...] O'Reilly 2000-06-26
[7] 웹사이트 The Kerberos Network Authentication Service (V5) https://tools.ietf.o[...]
[8] 웹사이트 The Kerberos Network Authentication Service (V5) https://tools.ietf.o[...]
[9] 웹사이트 What Is Kerberos Authentication? https://technet.micr[...] Microsoft TechNet 2009-10-08
[10] 웹사이트 Setspn - Windows CMD - SS64.com https://ss64.com/nt/[...]
[11] 웹사이트 Setspn | Microsoft Docs https://docs.microso[...]
[12] 웹사이트 Deprecate DES, RC4-HMAC-EXP, and Other Weak Cryptographic Algorithms in Kerberos https://tools.ietf.o[...]
[13] 웹사이트 http://web.mit.edu/k[...]
[14] 서적 Kerberos オライリー・ジャパン 2004-05-28
[15] 웹사이트 Source Browser https://opensource.a[...] 2019-08-12
[16] 서적 Kerberos オライリー・ジャパン 2004-05-28
[17] 웹사이트 e-words IT用語辞典 Kerberos 【 ケルベロス 】 http://e-words.jp/w/[...]
[18] 서적 Kerberos オライリー・ジャパン 2004-05-28
[19] 서적 Kerberos オライリー・ジャパン 2004-05-28
[20] 서적 コンピュータ・サイエンス誌 bit 共立出版 1990-07-01
[21] 서적 Kerberos オライリー・ジャパン 2004-05-28
[22] 서적 Kerberos オライリー・ジャパン 2004-05-28
[23] 서적 Kerberos オライリー・ジャパン 2004-05-28
[24] 웹인용 Kerberos 5 Release 1.21 https://web.mit.edu/[...]
[25] 간행물 RFC 4556, abstract



본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.

문의하기 : help@durumis.com