요약
- RFC 9867은
IKE_INTERMEDIATE와CREATE_CHILD_SA를 통해 사전 공유 키(PPK)를 IKEv2에 혼입하는 방법을 추가하며, 여기에는 Child SA나 IKE SA가 생성 또는 재키잉될 때 새 PPK를 사용하는 것이 포함된다. CREATE_CHILD_SA응답은 PPK 식별자를 생략한 채로도 일반 IKEv2 처리에 따라 새 SA를 생성할 수 있다. 이 폴백이 개시자의 정책에 위배되면 개시자는 프로토콜이 방금 만들어낸 것을 즉시 삭제할 수 있다.- SA별 PPK 혼입 영수증은 교환 완료, PPK 선택과 확인, 인가, 생성, 정책 수락, 사용 및 삭제를 구분해 기록해야 한다. 이는 Daniel Kade의 편집상 제안일 뿐이며 RFC나 IETF의 요구 사항이 아니다.
녹색 “SA 생성됨” 이벤트는 결정적으로 보인다. 인증된 제어 채널이 있었고 교환이 정상적으로 끝났으며 키 재료가 도출되었고 새로운 식별자 쌍이 시스템에 들어왔다. 운영 소프트웨어는 이를 집계할 수 있고 마이그레이션 대시보드는 이를 보고할 수 있으며 감사자는 몇 달 뒤 기록을 찾아 더 강한 정책이 적용되었다고 추론할 수 있다.
RFC 9867은 더 따가운 사실을 제시한다. 그 교환을 이끈 사전 공유 키 없이도 동일한 생성된 상태에 도달할 수 있다. 이것이 반드시 오류는 아니다. PPK 사용이 선택 사항이거나, 응답자가 지원 또는 구성을 갖추지 못했거나, 제안된 식별자가 일치하지 않거나, 동일해 보이는 식별자에 양측이 서로 다른 값을 연결하는 경우에는 명세된 결과일 수 있다. 프로토콜 진행과 보호 증거는 단순한 대시보드가 둘을 하나로 합치는 바로 그 순간에 갈라진다.
두 가지 확장, 하나의 양자내성 레이블이 아니다
IKEv2에는 암호학적 상태가 바뀔 수 있는 여러 뚜렷한 시점이 이미 존재한다. 기본 프로토콜은 초기 IKE SA, 인증된 교환, Child SA의 생성, 그리고 Child SA와 IKE SA 모두의 재키잉을 정의한다. “터널이 PPK를 사용한다”는 문장은 어떤 SA가, 어떤 교환에서, 어떤 도출 과정을 통해 키가 만들어졌는지 말해주지 않는다.
RFC 8784는 PPK를 IKEv2 세션 키에 혼입하는 한 가지 방법을 도입했다. 그 설계는 초기 설정 시점의 사용을 가정하며, 이후 작업이 다루는 하나의 경계를 유지한다. 즉 PPK를 초기 IKE SA 자체의 보호에는 사용하지 않는다. RFC 9867은 이 메커니즘을 지우지 않는다. 추가 경로를 정의한다.
첫 번째 경로는IKE_INTERMEDIATE, 즉 RFC 9242에서 별도로 정의된 인증 이전 교환을 사용한다. 개시자는 PPK 식별자를 제안할 수 있고, 응답자는 그중 하나를 선택해 확인 자료를 반환할 수 있다. 혼입은IKE_AUTH이전에 일어나므로 PPK가 초기 IKE SA와 그 인증 교환의 보호에 기여할 수 있다. 다른 중간 키 교환이 함께 있는 경우 PPK 연산은 다음 교환 전에 이루어지는 마지막 키 재계산이어야 한다. 따라서 순서는 구현 세부 사항이 아니라 보안 주장의 일부다.
두 번째 경로는CREATE_CHILD_SA를 사용한다. 기존 관계 전체를 해체하지 않고도 Child SA가 생성 또는 재키잉될 때, 그리고 IKE SA 자체가 재키잉될 때 새 PPK가 기여할 수 있게 한다. 이것은 로테이션을 운영상으로 가능하게 만든다. 동시에 하나의 장기 제어 관계 아래 여러 계보를 만든다. 오래된 IKE SA, 기존 Child SA, 새 Child SA, 재키잉된 IKE SA가 하나의 무차별적인 “PPK로 보호됨” 배지를 물려받을 수는 없다.
RFC 9370의 다중 키 교환 작업과 RFC 9838의 포스트 양자 하이브리드 용어는 중요한 맥락을 제공하지만 어느 쪽도 이 증거 문제를 해결하지 못한다. 알고리즘 목록은 사용 가능한 재료를 기술하고, 협상된 교환은 하나의 사건을 기술한다. 어느 쪽만으로는 특정 SA의 키에 어떤 기여가 닿았는지 증명할 수 없다.
식별자, 매칭, 인가는 별개다
RFC 9867은 두 개의 등록된 IKEv2 알림을 사용한다.USE_PPK_INT는 이 확장을 알리고,PPK_IDENTITY_KEY는 식별자와 관련 확인 자료를 운반한다. IANA는 이들을 알림 값 16445와 16446으로 기록한다. 이 눈에 보이는 프로토콜 요소들은 증거를 뒷받침하지만 비밀 그 자체는 아니며, 이를 기록할 면허로 취급해서는 안 된다.
확인값은 정의된 컨텍스트에 대해 협상된 의사난수 함수 출력의 처음 8옥텟으로 도출된다. 이를 통해 교환은 두 피어가 동일해 보이는 PPK 식별자를 선택했지만 서로 다른 PPK 값을 갖는 경우를 감지할 수 있다. 이는 구성 일치보다 강한 진술이다. 그래도 완전한 인가보다는 좁다.
IKE_INTERMEDIATE에서 응답자는 개시자의 인증된 신원을 알기 전에 PPK를 선택해야 할 수 있다. 인증이 그 신원을 드러낸 뒤, 로컬 정책은 선택된 PPK가 이 피어에 적합하지 않았다고 판단할 수 있다. RFC 9867은 그런 상황에서 응답자가 중단해야 한다고 말하면서, 로컬 정책이 허용하면 계속 진행할 수 있게 허용한다. 따라서 일치하는 재료의 보유와 그 재료 사용의 허가는 서로 다른 시점에 서로 다른 정보로 내려지는 별개의 결정이다.
이 경계는 자동화에서 잃기 쉽다. 키 스토어 조회는 “발견됨”이라 말할 수 있다. 확인값은 “동일한 값”이라 말할 수 있다. 인증은 “이 피어”라 말할 수 있다. 그래도 정책은 그 피어가 그 PPK로 이 SA를 수립하는 것이 허용되는지 말해야 한다. 단 하나의 성공 불리언은 이 순서를 보존할 수 없다.
정책에 실패하기 전에 성공하는 SA
가장 날카로운 사례는CREATE_CHILD_SA에서 발생한다. 개시자가 새 PPK를 사용하겠다고 요청한다. 응답자는 이 확장을 구현하지 않았거나, 구성하지 않았거나, 제안된 식별자를 인식하지 못하거나, 일치하는 식별자에 다른 값을 연결하고 있을 수 있다. 이런 경우 그 응답은PPK_IDENTITY_KEY를 생략하며, 그럼에도 일반 IKEv2 처리가 새 SA를 만들어 낼 수 있다.
개시자에게 PPK 사용이 선택 사항이었다면 이 새 SA는 수락되어 사용될 수 있다. PPK 사용이 필수였다면 동일한 생성된 SA는 부적절하다. 개시자는 그것을 즉시 삭제할 수 있다. 양쪽 시스템 모두 프로토콜에 일관되게 행동했는데도 수명 주기에는 생성 카운터가 오분류하게 될 일시적 상태가 존재한다.
이제 세 개의 시점이 중요해진다: SA가 생성된 때, 로컬 정책이 PPK 증거의 부재를 평가한 때, 그리고 SA가 삭제 또는 수락된 때. 패킷 결과도 중요하다. 삭제 전에 보호된 트래픽이 이 SA를 사용했는가? 페일오버 시스템이 트래픽을 이 경로로 보냈는가? 개시자가 제거한 뒤에도 피어는 그것이 존재한다고 믿었는가? 표준은 교환 동작을 정의하지만, 운영상 질문에 답할 증거는 여전히 운영자가 소유한다.
“필수” 역시 소유자와 범위가 필요하다. 그것은 한 피어, 한 트래픽 클래스, 한 재키잉 작업 또는 한 마이그레이션 단계에 대한 정책일 수 있다. PPK 지원 소프트웨어의 존재에서 추론할 수 있는 속성이 아니다. 선택적 폴백은 의도적인 상호운용성 정책일 수 있다. 거버넌스 실패는 폴백이 존재한다는 것이 아니다. 더 강한 상태가 입증된 것처럼 폴백을 보고하는 것이다.
키가 아니라 키 전환에 대한 영수증
여기서 제안하는PPK 혼입 영수증은 편집상 제어 기록이다. IETF 필드가 아니며 PPK 비밀을 절대 담아서는 안 된다.
새로 생성되거나 재키잉된 각 SA에 대해 교환 유형과 상위 IKE-SA 계보를 기록한다. 그 사건이 RFC 8784를 따랐는지, RFC 9867 경로 중 하나를 따랐는지 식별한다. 비밀이 아닌 PPK 식별자 또는 개인정보 보호 핑거프린트, 제안 및 선택 상태, 확인 결과, 피어 인증이 사용 가능해진 시점을 보존한다. 양측에 적용되는 필수-선택 정책을 로컬에서 알 수 있는 범위까지, 그리고 결정 소유자와 정책 버전을 기록한다.
그다음 도출 순서를 기록한다. 여러 중간 교환이 키 재료를 바꾸었다면, 이 경로에 요구되는 대로 PPK 연산이 마지막이었는가? 영수증을 결과 SA 식별자에 결합하되, 식별자 자체가 보호를 증명한다고 가장하지 않는다. 생성됨, 수락됨, 설치됨, 사용 관찰됨, 삭제됨을 별개의 상태로 유지한다. 폴백 또는 삭제 이유, 예외 소유자, 롤백 결정, 다음 검토 시점을 추가한다.
이 기록은 관측 가능성 한계를 존중해야 한다. 네트워크 추적은 알림과 트래픽을 보여줄 수 있지만 구현 내부의 비밀 키 스케줄 상태를 증명하지는 못할 수 있다. 구현 이벤트는 노출 없이 어떤 기여가 적용되었음을 증언할 수 있다. 벤더 간 주장에는 신중하게 범위가 지정된 신뢰가 필요하다. 영수증은 각 관측을 어떤 구성 요소가 했는지, 그리고 어떤 부분이 추론으로 남는지 밝혀야 한다.
최소한으로 유용한 질문은 “IKE가 성공했는가?”가 아니다. 질문은 이것이다: 이 SA에 대해, 이 계보와 이 정책 아래에서, 어떤 증거가 의도된 PPK 기여가 올바른 도출에 올바른 시점에 들어갔음을 보여주고, 로컬 결정 이후 SA에 무슨 일이 일어났는가?
마이그레이션 주장은 SA 경계에서 마감되어야 한다
포스트 양자 동기에는 정밀함이 필요하다. RFC 9867은 대칭 프리미티브가 현재 논의 중인 공개 키 메커니즘과 동일한 수준의 암호학적으로 관련성 있는 양자 컴퓨터 위험에 직면한다고 현재 믿어지지 않는다고 설명한다. 따라서 인증 전에 강한 PPK를 혼입하는 것은 보호 경로를 추가할 수 있다. 그 진술은 유능한 기계의 존재에 대한 예측이 아니고, 그런 기계의 시간표도 아니며, 어떤 제품이나 배포가 양자 안전하다는 인증서도 아니다.
신선함 역시 여기서는 좁은 의미를 갖는다. 이 메커니즘은 서로 다른 PPK가 새로운 또는 재키잉된 SA에 기여할 때 유용하다. 같은 낡은 PPK로 호출하면 그 로테이션에서 아무 의미가 없다. 운영상 키 보관, 엔트로피, 배포, 침해 대응은 교환 완료만으로 증명할 수 있는 범위 밖에 있다.
가장 강한 마이그레이션 보고서는 그러므로 전 단위 형용사를 피한다. 정확한 SA 수, 정확한 경로, 정확한 결과를 세어 보고한다. 어떤 것은 RFC 8784를 통해 보호될 수 있다. 어떤 것은 RFC 9867 중간 경로를 사용한다. 어떤 것은 재키잉 시 새 PPK를 사용한다. 어떤 것은 선택적 정책 아래에서 정당하게 폴백한다. 어떤 것은 필수 정책이 충족되지 않아 생성 후 삭제된다. 압축해야 할 지저분한 데이터가 아니라 실제 결정 표면이다.
프로토콜 설계는 종종 진행을 허용한다. 네트워크가 고르지 않은 구현과 정책을 가로질러 계속 운영되어야 하기 때문이다. 거버넌스는 어떤 종류의 진행이 일어났는지 보존해야 한다. RFC 9867은 운영자에게 유연한 전환 메커니즘을 준다. 하지만 “생성됨”을 수집된 적 없는 증거로 바꾸게 해주지는 않는다.
출처
- RFC 9867의 IETF Datatracker 기록
- Lu Heng: 최소 초기 명세, 지역화된 미래 결정, 자발적 채택
- Lu Heng: BTW Media가 존재하는 이유에 대하여
- Lu Heng: 정책의 거울
- IANA IKEv2 파라미터
- RFC 9867의 RFC Editor 기록
- RFC 7296: 인터넷 키 교환 프로토콜 버전 2
- RFC 8784: IKEv2에서의 사전 공유 키 혼입
- RFC 9242: IKEv2의 중간 교환
- RFC 9370: IKEv2의 다중 키 교환
- RFC 9838: 포스트 양자 전통 하이브리드 체계의 용어
- RFC 9867: IKE_INTERMEDIATE와 CREATE_CHILD_SA에서의 사전 공유 키 혼입
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





