키의 Kerberized 인터넷네고시에이션
Kerberized Internet Negotiation of KeysKerberized Internet Negotiation of Keys(KINK)는 Internet Key Exchange(IKE; 인터넷키 익스체인지)와 마찬가지로 IPsec Security Association(SA; 보안 어소시에이션)을 설정하기 위해 RFC 4430에서 정의된 프로토콜입니다.Kerberos 프로토콜을 사용하여 신뢰할 수 있는 서드파티가 피어 인증 및 보안 정책 관리를 일원 [1]관리할 수 있도록 합니다.
그 동기는 IKE의 대체 수단으로서 RFC 3129에 기재되어 있습니다.IKE에서는, 피어는 각각 인증에 X.509 증명서를 사용할 필요가 있습니다.Diffie:암호화용 Hellman Key Exchange(DH; Hellman 키 교환)는 접속하는 [2]모든 피어에 대해 보안 정책을 인식하고 구현합니다.X.509 증명서의 인증은 사전에 예정되어 있거나 DNSSEC를 [3]사용하는 것이 좋습니다.KINK 피어는 Kerberos를 사용하여 적절한 Authentication Server(AS; 인증 서버)와 Key Distribution Center(KDC; 키 배포 센터)를 상호 인증하고 암호화용 키잉 자료의 배포를 제어하여 IPsec 보안 정책을 제어해야 합니다.
프로토콜 설명
KINK는 IPsec SA를 작성, 삭제 및 유지관리할 수 있는 명령어/응답 프로토콜입니다.각 명령어 또는 응답에는 type-length-value payload 세트와 함께 공통 헤더가 포함되어 있습니다.명령어 또는 응답 유형에 따라 교환 메시지로 전송되는 payload가 제한됩니다.
KINK 자체는 각 명령 또는 응답에 KINK용 하드스테이트의 저장이 필요 없다는 점에서 스테이트리스 프로토콜입니다.이는 메인 모드를 사용하여 먼저 Internet Security Association and Key Management Protocol(ISAKMP) SA를 확립하고 그 후 Quick Mode 교환을 수행하는 IKE와는 대조적입니다.
KINK는 Kerberos 메커니즘을 사용하여 상호 인증 및 재생 보호를 제공합니다.SA를 확립하기 위해 KINK는 Kerberos AP-REQ payload에 이은 payload의 기밀성을 제공합니다.KINK 설계에서는 공개 키 조작 및 상태 설치 전에 인증된 교환을 요구함으로써 서비스 거부 공격을 완화할 수 있습니다.KINK는 서버와 KDC 간에 공유되는 키가 없는 경우에도 Kerberos 사용자 간 메커니즘을 사용할 수 있습니다.이것은, 통상, 초기 인증에 PKINIT 를 사용하고 있는 IPsec 피어(peer)의 경우에 한정되는 것은 아닙니다.
KINK는 IKE 섹션 5.5에서 정의된 퀵모드 페이로드를 직접 재사용하지만 약간의 변경이나 누락이 있습니다.대부분의 경우 KINK 교환은 단일 명령어와 그 응답입니다.SA를 작성할 때 옵션의 세 번째 메시지가 필요한 것은 응답측이 발신측으로부터의 첫 번째 제안을 거부하거나 키 입력 자료를 제공하려는 경우뿐입니다.KINK는 키 재생성 및 데드 피어 검출도 제공합니다.
패킷 형식
KINK 메시지에는 다음 필드가 있습니다.
| 비트 오프셋 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 유형 | 버전 | 길이 | |||||||||||||||||||||||||||||
| 32 | 통역 영역(DOI) | |||||||||||||||||||||||||||||||
| 64 | 트랜잭션 ID(XID) | |||||||||||||||||||||||||||||||
| 96 | 다음 페이로드 | A | 체크섬 길이 | |||||||||||||||||||||||||||||
| 128 ... | 페이로드 ... | |||||||||||||||||||||||||||||||
| ... ... | 체크섬 ... | |||||||||||||||||||||||||||||||
- 유형: CREATE, DELETE, REPLY, GETTGT, ACK, STATUS 또는 프라이빗 사용
- 버전: 메이저 프로토콜 버전 번호
- length: 메시지 길이
- 도메인 오브 인터프리터(DOI): Internet Security Association and Key Management Protocol(ISAKMP)에서 정의된 DOI
- 트랜잭션 ID(XID): 명령어, 응답 및 옵션 확인 응답으로 정의된 트랜잭션 식별
- next payload: 메시지헤더 뒤의 첫 번째 payload 유형(KINK_DONE, KINK_AP_)REQ, KINK_AP_REP, KINK_KRB_ERROR, KINK_TGT_REQ, KINK_TGT_REP, KINK_ISAKMP, KINK_ENCrypt 또는 KINK_ERROR
- ACK 또는 ACKREQ 비트: 응답측에서 REPLY가 수신된 것을 명시적으로 확인할 필요가 있는 경우1 이외의 경우는 0
- 체크섬 길이: 메시지의 암호화 체크섬 길이(바이트 단위)
- 페이로드: Type/Length/Value(TLV; 유형/길이/값) 페이로드 목록
- 체크섬:Kerberos가 체크섬필드 자체를 제외한 메시지 전체에 체크섬 키를 입력했다.
페이로드
KINK payload는 다음과 같이 정의됩니다.
| 비트 오프셋 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | 다음 페이로드 | 페이로드 길이 | ||||||||||||||||||||||||||||||
| 32 ... | 가치 ... | |||||||||||||||||||||||||||||||
- next payload: 첫 번째 payload
- 길이: 페이로드 길이
다음 payload가 정의되어 있습니다.
- KINK_AP_REQ: Kerberos AP-REQ를 응답 측에 릴레이하는 페이로드
- KINK_AP_REP: Kerberos AP-REP를 이니시에이터로 릴레이하는 페이로드
- KINK_KRB_ERROR: Kerberos 유형의 오류를 이니시에이터로 릴레이하는 페이로드
- KINK_TGT_REQ:KDC에서 User-to-User 서비스 티켓을 취득하기 위해 피어에서TGT를 취득하는 수단을 제공하는 페이로드
- KINK_TGT_REP: GETTGT 명령어의 이전 KINK_TGT_REQ 페이로드에서 요청된 TGT를 포함하는 페이로드
- KINK_ISAKMP: ISAKMP IKE Quick Mode(단계 2) payload를 캡슐화하는 페이로드. 후속 리비전이 있을 경우 IKE 및 ISAKMP와의 하위 호환성을 가능하게 합니다.
- KINK_ENCrypt: 다른 KINK payload를 캡슐화하기 위한 payload로 세션키와 그 etype으로 지정된 알고리즘을 사용하여 암호화됩니다.
- KINK_ERROR: 오류 조건을 반환하는 페이로드
실장
「 」를 참조해 주세요.
레퍼런스
- ^ RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 2
- ^ RFC 3129: Requirements for Kerberized Internet Negotiation of Keys, Internet Engineering Task Force, June 2001, p. 1
- ^ RFC 4322: Opportunistic Encryption using the Internet Key Exchange (IKE), Internet Engineering Task Force, June 2001, p. 5
